https://wiki.archlinux.org/api.php?action=feedcontributions&user=Steno&feedformat=atomArchWiki - User contributions [en]2024-03-29T04:58:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Operazioni_Preliminari&diff=36933Small Business Server (Italiano)/Operazioni Preliminari2008-02-11T16:08:11Z<p>Steno: /* cpan4pacman */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
ArchLinux su di un server ? E perchè no ? La sua semplicità di gestione unita al fatto che ''solo i servizi necessari'' saranno installati e configurati, secondo me fanno di Arch una ottima soluzione lato server. In questa serie di articoli installeremo e configureremo un piccolo (ma neanche tanto) server tuttofare basandoci sulla nostra ditribuzione preferita. Mettiamoci comodi ed iniziamo con le operazioni preliminari.<br />
= Operazioni Preliminari =<br />
Iniziamo la configurazione del nostro ArchLinux SBS con delle operazioni preliminari per rendere la nostra box pronta al via.<br />
== Convenzioni ==<br />
* eth0 sarà la scheda ethernet collegata alla nostra LAN. Verrà fornita di un indirizzo IP statico.<br />
* eth1 sarà la scheda ethernet collegata a internet (o alla WAN). Avrà un indirizzo IP statico (se disponibile) o assegnato dal provider con DHCP. Attenzione: se volessi configurare la mia box come server VPN un indirizzo statico è consigliato.<br />
* 192.168.20.0/24 è la mia rete interna<br />
* 192.168.20.1 è l'indirizzo IP statico assegnato a eth0<br />
* il nostro server si chiama ''archi'' (che fantasia!)<br />
* il nostro dominio sarà ''mede.it''<br />
* il nostro utente amministrativo sarà ''admin''<br />
<br />
Iniziamo a preparare il nostro '''''archi.mede.it ''''' :)<br />
= Preparare il sistema =<br />
== Aggiornamento pacchetti ==<br />
Prima di iniziare rendiamo la nostra installazione aggiornata alle ultime versioni dei pacchetti disponibili.<br />
pacman -Syu<br />
=== Pacchetti aggiuntivi indispensabili ===<br />
==== yaourt ====<br />
yaourt è un pacchetto che, con una sintassi uguale a pacman, ci permette di installare direttamente anche da AUR. Naturalmente questa opzione và usata con cautela, ma nel proseguo della nostra guida ci sarà indispensabile.<br />
Creiamo una directory "yaourt" nella home e posizioniamoci ("mkdir yaourt" e cd "yaourt" insomma) e scarichiamo i files necassari :<br />
pacman -S diffutils<br />
wget http://aur.archlinux.org/packages/yaourt/yaourt/PKGBUILD<br />
wget http://aur.archlinux.org/packages/yaourt/yaourt/yaourt.install<br />
e creiamo il pacchetto :<br />
makepkg<br />
finita l'installazione vi troverete il pacchetto pronto. Installiamolo con <br />
pacman -A yaourt-0.8.4-1-i686.pkg.tar.gz<br />
ora abbiamo il pacchetto pronto all'uso.<br />
<br />
Per utilizzare anche gli ultimi aggiornamenti CVS/SVN/mercurial installiamo anche versionpkg<br />
pacman -S versionpkg<br />
==== cpan4pacman ====<br />
Questo non è che è indispensabile, ma molto utile sì. Questo pacchetto fà qualcosa di simpatico: ''scarica i moduli perl che gli indichiamo da CPAM e li trasforma in pacchetti per Arch''. Il che, ripeto, non è che sia proprio indispensabile, ma molto utile per mantenere solo software pacchettizzato sulla nostra box questo sì.<br />
pacman -S perl-cpanplus-pacman<br />
Appena finito di installare dobbiamo aggiornare il nostro albero ''ABS'' :<br />
pacman -S cvsup abs<br />
abs core extra community<br />
e creare il database dei moduli perl disponibili nei repositories di Arch Linux.<br />
cpan4pacman --abs-cache<br />
Ora sarà possibile creare il pacchetto della libreria perl con (esempio Net::Server) :<br />
cpan4pacman Net::Server<br />
Molto utile, ci servirà.<br />
<br />
=== Rimozione pacchetti inutili ===<br />
Facciamo "dimagrire" il più possibile la nostra installazione rimuovendo tutti i pacchetti per noi inutili. Meno pacchetti significa meno problemi di sicurezza e maggior velocità negli aggiornamenti. Perchè tenere quello che non mi serve ? Cominciamo con eliminare eventuali pacchetti orfani, pacchetti, cioè, che non sono utilizzati da nessuno e che possono quindi essere fatti scomparire.<br />
<br />
Comuque diamo prima un occhio ai nostri pacchetti orfani :<br />
pacman -Qe | less<br />
Se ci sono dubbi con un <br />
pacman -Qi <nome pacchetto><br />
ho delle info aggiuntiva sullo stesso. Spariti i miei dubbi eliminiamo tutti gli orfani (si fà per dire :D)<br />
pacman -Qer<br />
Ora potrei eliminare tutti quei pacchetti che non mi servono, una buona lista da cui partire potrebbe essere questa :<br />
* hwd: Dal momento che conosco il mio hardware ...<br />
* lshwd: una dipendenza di hwd<br />
* pcmciautils: Non credo che il nostro server utilizzi hardware PCMCIA/Cardbus.<br />
* grub / lilo: Eliminiamo quello che non viene usato.<br />
* nano / vim: Tenete il vostro editor preferito. Se siete come me che non ha mai imparato ad usare vim (vergogna!), rimuovetelo e tenetevi nano. Tanto per complicare le cose io uso joe come editor ..<br />
* raidtools: serve solo se utilizzate RAID. Altrimenti raus !<br />
* e2fsprogs / jfsutils / reiserfsprogs / xfsprogs: tenere solo il pacchetto corrispondente al filesystem usato.<br />
* wireless_tools: se non intendete fare un wireless gateway rimuovetelo pure.<br />
<br />
Per rimuoverli completamente :<br />
<br />
pacman -Rn pacchetto1 pacchetto2 pacchetto3<br />
= Amministrazione remota con OpenSSH =<br />
Se vogliamo amministrare remotamente il nostro server dobbiamo installare e configurare openssh. Non vorrete mica ogni volta andare davanti alla console ! :D<br />
== Installazione ==<br />
Installazione e avvio del servizio :<br />
pacman -S openssh<br />
<br />
/etc/rc.d/sshd start<br />
Se ora tento di connettermi da un'altra macchina via rete ottengo un bel "Connection refused". Devo editare il file /etc/hosts.allow e aggiungere gli hosts abilitati. Per ora (orrore!) abilitiamo tutti:<br />
nano /etc/hosts.allow<br />
e aggiungiamo la riga :<br />
sshd sshd1 sshd2 : ALL : allow<br />
Ora '''qualunque host/Indirizzo IP''' può tentare di connettersi remotamente. Non è una buona idea, internet è pieno di "cattivi" meglio ridurre al minimo i rischi.<br />
== Configurazione ==<br />
Per ridurre (magari si potesse azzerarli) i rischi di sicurezza editiamo il file di configurazione :<br />
nano /etc/ssh/sshd_config<br />
e inseriamo (o togliamo il commento) almeno queste voci:<br />
#Cambiamo la porta di default (da 22 a 2223) e accettiamo solo connessioni dalla rete interna<br />
#Se, come capita spesso, dovete remotamente amministrare il vostro server da internet mettete solo Port 2223<br />
#a questo punto scegliete una password "robusta" per il vostro utente amministratore<br />
ListenAddress 192.168.10.1:2223<br />
#Abilitiamo solo il nostro utente a collegarsi (esempio admin da ovunque, foobar solo dall'host 192.168.10.20)<br />
AllowUsers admin foobar@192.168.10.20<br />
#Rifiutiamo le connessioni con l'utente root. Meglio usare admin e poi su se non ho abilitato sudo<br />
#Se ho installato sudo e disabilitato root non serve<br />
DenyUsers root<br />
PermitRootLogin no<br />
#Abilita solo il protocollo ssh2 molto più sicuro di ssh1<br />
Protocol 2<br />
e riavviamo il servizio con <br />
/etc/rc.d/sshd restart<br />
Ora non ci resta che editare il nostro rc.conf per abilitare il daemon sshd ad ogni riavvio:<br />
nano /etc/rc.conf<br />
e modificare la riga DAEMONS aggiungendo sshd<br />
DAEMONS=(... ... ... ... ... sshd ... ... ...)<br />
== Configurazione schede di rete ==<br />
Anche se non c'entra con OpenSSH, preparamo le schede di rete con la configurazione che ci servirà: editiamo ancora una volta il nostro /etc/rc.conf e nella sezione ''network config'' impostiamo gli indirizzi IP. Ne nostro esempio per la rete interna connessa a eth0 la classe C completa :<br />
* network address : 192.168.20.0<br />
* gateway : 192.168.20.1<br />
* netmask : 255.255.255.0<br />
* broadcast : 192.168.20.255<br />
lo="lo 127.0.0.1"<br />
eth0="eth0 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255"<br />
eth1="dhcp"<br />
Nell'esempio eth1 dispone di un indirizzo IP dinamico assegnato dal provider (o dal router DSL, o da quello che avete). Se disponiamo di un indirizzo statico inseriamolo qui nella riga "eth1".<br />
= Sudo =<br />
== Introduzione ==<br />
Nei sistemi operativi Unix/Linux c'è un utente particolare, detto super utente e contraddistinto dall'avere un UID (User ID) uguale a 0 e nome utente '''root''', che ha totale accesso al sistema senza nessuna restrizione, è l' amministratore del sistema.<br />
<br />
Nella maggior parte dei sistemi GNU/Linux, l'amministratore del computer non usa l'utente amministratore (per motivi di sicurezza) ma usa un utente normale per svolgere il lavoro quotidiano. Quando ha la necessità di svolgere mansioni di amministrazione apre un terminale e avvia una sessione come utente root, oppure se si trova già in un terminale come utente normale usa il comando '''su''' per diventare utente root.<br />
<br />
Io preferisco usare un approccio diverso per svolgere mansioni amministrative, basato sull'utilizzo del comando '''sudo'''. Qui esistono diverse scuole di pensiero in merito alla sicurezza di '''sudo''' rispetto a '''su'''.<br />
<br />
In ognuno dei due modelli, sudo e su, ci sono vantaggi e svantaggi.<br />
<br />
Siccome sudo costringe l'esecuzione controllata di singoli comandi ha questi vantaggi:<br />
* Riduce il tempo in cui gli utenti sono nel sistema come root e quindi riduce i rischi di lanciare inavvertitamente comandi dannosi per il sistema.<br />
* Aumenta la possibilità di ricerca e analisi sul sistema grazie al log dei comandi.<br />
<br />
Di contro, se qualcuno scopre la password di un utente abilitato all'utilizzo di sudo come root in effetti può ottenere accesso come root. Nel caso di utilizzo di sudo bisogna prestare una maggiore attenzione alla scelta della password utente.<br />
I sostenitori del modello su, cioè account di root abilitato e utilizzo di una shell di root per compiti amministrativi, sostengono che su sia più sicuro in quanto il livello di root si ottiene dopo l'inserimento di due password, la password utente e la password di root.<br />
D'altra parte, chi cerca di entrare in un sistema ha la necessità di scoprire due cose, il nome utente e la password. Con l'account di root abilitato, una delle due è già nota, serve solo scoprire la password. Con sudo si devono scoprire entrambe (nome utente e password).<br />
Quando in un sistema alcuni compiti amministrativi sono assegnati a vari utenti, l'utilizzo di sudo evita di dover dare la password di root a più utenti. L'amministratore può assegnare a qualsiasi utente, temporaneamente, privilegi particolari, eliminandoli o limitandoli quando non vi è più necessità.<br />
<br />
== Il comando sudo ==<br />
'''sudo''' (superuser do) consente di eseguire un comando come se si fosse un altro utente. Effettua una specie di sostituzione, previa autorizzazione, tra l'utente attuale (colui che esegue il comando sudo) e l'utente target (colui che esegue l'effettivo comando). Mentre con il comando '''su''' si cambia utente fino al termine della sessione del terminale, sudo assegna i privilegi dell'utente target al solo processo (e ai suoi processi figli) che viene con esso avviato.<br />
<br />
Per eseguire dei comandi con privilegi d'amministrazione è sufficiente digitare sudo e successivamente il comando che si desidera eseguire come utente root, come nel seguente esempio:<br />
sudo nano /etc/rc.conf<br />
Una volta digitato il comando, il sistema chiederà la password dell'utente attuale e non la password dell'utente target. La password viene chiesta la prima volta e memorizzata per un certo lasso di tempo, quindi è possibile usare il comando sudo più volte consecutive senza dover inserire ogni volta la password.<br />
<br />
Con sudo l'amministratore del sistema può assegnare privilegi particolari a qualsiasi utente, definire quali comandi far eseguire e quali no e avere il log (/var/log/auth.log) di tutte le operazioni effettuate su tentativi di accesso non autorizzati.<br />
== Creazione di un utente amministrativo ==<br />
A me piacciono i sistemi ''"rootless"'', cioè privi dell' utente ''"root"'' che tanti problemi di sicurezza può causare. Quindi creiamo un utente amministrativo con una solida password. In seguito a questo utente assegneremo privilegi particolari per poter disabilitare root e amministrare il sistema.<br />
Siccome sono a corto di idee chiamo questo utente "admin"<br />
adduser admin<br />
Lasciamo le impostazioni di default e assegniamo una bella password '''che naturalmente non si deve dimenticare''' e proseguiamo.<br />
== Installazione di sudo ==<br />
Per installare sudo :<br />
pacman -S sudo<br />
== Configurazione ==<br />
Per abilitare il nostro utente "admin" a svolgere i compiti amministrativi utilizzando sudo devo aggiungerlo al file /etc/sudoers. Per editare questo file '''devo''' utilizzare il comando :<br />
visudo<br />
che apre il file utilizzando l'editor vim (che io conosco ben poco...). visudo controlla quanto scrivete su questo importantissimo file evitando possibili errori di sintassi. Se non conoscete vim vediamodi arrangiarci lo stesso :)<br />
* spostatevi nella sezione "User privilege specification" ci dovrebbe essere una riga con 'root'<br />
* premete il tasto '''i''' (insert) create una riga vuota e scrivete :<br />
admin ALL=(ALL) SETENV: ALL<br />
* premete '''ESC''' (con cui uscite dal modo insert)<br />
* digitate ''':x''' per salvare e uscire<br />
<br />
Ora l'utente "admin" dovrebbe essere abilitato al comando "sudo". Prima di proseguire provate a loggarvi sulla console con l'utente admin e poi provate, ad esempio:<br />
sudo nano /etc/rc.conf<br />
dopo aver digitato la password di admin provate a salvare il file, se non vi dà errore tutto è filato liscio.<br />
== Disabilitare l'utente root ==<br />
Quando siete sicuri che admin abbia i privilegi di amministrazione attraverso sudo possiamo disabilitare l'utente root:<br />
sudo passwd -l root<br />
In caso di pentimento potete riabilitarlo con:<br />
sudo passwd root<br />
Il nostro sistema "rootless" è pronto. Da ora in avanti ci loggheremo alla console con il nostro utente admin e utilizzeremo sudo per i compiti amministrativi.<br />
= Operazioni aggiuntive =<br />
Per terminare questa sezione preliminare '''non dimenticate''' di :<br />
* assegnare un nome al vostro server (sempre su /etc/rc.conf, ma serve dirlo ?)<br />
* aggiungere il nome del server al file /etc/hosts accanto a localhost<br />
127.0.0.1 localhost archi<br />
* impostare il nome del dominio ed eventualmente il DNS nel caso non vi venga assegnato dal provider in /etc/resolv.conf<br />
search mede.it<br />
nameserver xxx.xxx.xxx.xxx<br />
<br />
Bene. Terminate le operazioni prelimiari non abbiamo ancora fatto niente :D.<br />
<br />
Ma chi ben inizia ...</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36248Small Business Server (Italiano)/File Server Domain Controller2008-01-30T17:35:30Z<p>Steno: /* LDAP Tools */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba''' che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''"access to attrs=userPassword,sambaNTPassword,sambaLMPassword"'' che di fatto permette ai singoli utenti di cambiare la propria password direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5 e in ''/etc/ldap.secret'' in chiaro.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia di ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36247Small Business Server (Italiano)/File Server Domain Controller2008-01-30T17:34:30Z<p>Steno: /* LDAP Tools */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba''' che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''"access to attrs=userPassword,sambaNTPassword,sambaLMPassword"'' che di fatto permette ai singoli utenti di cambiare la propria password direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5 e in chiaro sul file ''/etc/ldap.secret''.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia di ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36246Small Business Server (Italiano)/File Server Domain Controller2008-01-30T17:32:22Z<p>Steno: /* OpenLDAP server */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba''' che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''"access to attrs=userPassword,sambaNTPassword,sambaLMPassword"'' che di fatto permette ai singoli utenti di cambiare la propria password direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia di ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36245Small Business Server (Italiano)/File Server Domain Controller2008-01-30T17:29:44Z<p>Steno: /* Samba */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba''' che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia di ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server/DNS_dinamico_e_DHCP_(Italiano)&diff=36244Small Business Server/DNS dinamico e DHCP (Italiano)2008-01-30T17:27:14Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= DNS Dinamico e DHCP =<br />
I servizi [http://it.wikipedia.org/wiki/Domain_Name_System DNS (Domain Name System)] e [http://it.wikipedia.org/wiki/DHCP DHCP (Dynamic Host Configuration Protocol)] oramai da tempo sono diventati una soluzione obbligata in una rete locale, e considerando che i nostri client di rete saranno tutti (o quasi) Windows XP che utilizzano il DNS come protocollo primario di risoluzione dei nomi sulla rete, non possiamo assolutamente tralasciarli.<br />
Vi è mai capitata una rete di PC peer to peer con Windows XP e accesso ad internet condiviso in cui il ''browsing della rete'' locale era lentissimo ? A me parecchie volte, ed è uno dei motivi per cui non ci si dovrebbe cimentare in queste cose senza capire quello che si stà facendo. Il browsing della rete era lentissimo perchè XP prima interroga il DNS per conoscere il nome dell'host e solo dopo usa il suo simpatico broadcast o il file HOSTS. Bene, considerate che il DNS della rete era quello del provider e comincerete a capire perchè era così lento ... :D.<br />
In GNU/Linux i pacchetti che la fanno da padrone in questo campo sono [http://www.isc.org/sw/bind bind] e [http://www.isc.org/sw/dhcp dhcpd], ma data la semplice natura della nostra rete optiamo per un pacchetto più semplice che integra tutto quello che ci server: ''DNS dinamico, DHCP e Caching''. Ottenere la stessa cosa con bind e dhcpd è un po' più complicato e magari ci torneremo su.<br />
Il pacchetto che utilizzeremo si chiama [http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] e offre, ma non solo, le seguenti funzionalità :<br />
* La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.<br />
* I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.<br />
* Dnsmasq ricava i nomi dal file /etc/hosts file del firewall: se il nome della macchina locale richiesta viene trovato, si viene immediatamente indirizzati alla stessa senza il bisogno di mantenere il file hosts in ogni macchina.<br />
* Il servizio DHCP server integrato supporta DHCP leases statici e dinamici e IP ranges multipli. Le macchine configurate con DHCP vengono automaticamente inserite nel DNS, e i nomi possono essere specificati in ogni macchina o centralmente associando il nome al MAC address nel file di configurazione di dnsmasq.<br />
* Dnsmasq esegue il ''caching'' degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.<br />
* Dnsmasq supporta i records di tipo ''MX'' e ''SRV'' e può essere configurato per fornire il record MX per alcune o tutte le macchine della rete locale.<br />
== Installazione ==<br />
Il pacchetto (tanto per cambiare) lo si installa così:<br />
sudo pacman -S dnsmasq dnsutils<br />
== Configurazione ==<br />
Editiamo il file di configurazione :<br />
sudo nano /etc/dnsmasq.conf<br />
Il file è ben commentato. Impostiamo i seguenti parametri :<br />
addn-hosts=/etc/dnshosts<br />
no-hosts<br />
local=/mede.it/<br />
interface=eth1<br />
expand-hosts<br />
domain=mede.it<br />
dhcp-range=192.168.20.50,192.168.20.150,12h<br />
dhcp-option=option:router,192.168.20.1<br />
dhcp-option=44,192.168.20.1 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)<br />
dhcp-option=45,192.168.20.1 # netbios datagram distribution server<br />
dhcp-option=46,8 # netbios node type<br />
dhcp-option=47 # empty netbios scope.<br />
dhcp-option=6,192.168.20.1<br />
mx-host=archi.mede.it,50<br />
mx-target=archi.mede.it<br />
localmx<br />
log-queries<br />
log-dhcp<br />
Per vedere tutti i parametri "dhcp-options" possibili eseguite il comando :<br />
dnsmasq --help dhcp<br />
Per le spiegazioni sui singoli parametri fate riferimento alla guida in linea<br />
man dnsmasq<br />
oppure ai commenti dello stesso file di configurazione.<br />
<br />
Ora modifichiamo il nostro file /etc/resolv.conf<br />
sudo nano /etc/resolv.conf<br />
che deve contenere i DNS che il server interroga, cioè se stesso e in seconda battuta il DNS del provider di cui farà la cache (ad esempio 151.99.125.1)<br />
search mede.it<br />
nameserver 127.0.0.1<br />
nameserver 151.99.125.1<br />
Se voglio utilizzare degli indirizzi statici basta inserirli nel file /etc/dnshosts (come speficato dal parametro ''addn-hosts'') nella solita forma (senza dominio, quello lo fornisce dnsmasq) che si usa per il file /etc/hosts. Ad esempio mettiamo il nostro server principale (a cui diamo anche i nomi "mail" e "proxy" ad esempio) e un altro con IP fisso :<br />
192.168.20.1 archi mail proxy<br />
192.168.20.2 myserver<br />
dnsmasq fornirà la risoluzione anche di myserver o myserver.mede.it a tutte le macchine della rete.<br />
<br />
Non uso il predefinito file ''/etc/hosts'' usato da dnsmasq per evitare che il DNS si metta a risolvere anche i nomi "privati" che potrei mettere qui, tipo ad esempio ''localhost''.<br />
<br />
== Avvio del servizio ==<br />
Ora possiamo avviare il servizio:<br />
sudo /etc/rc.d/dnsmasq start<br />
e modificare la riga DAEMONS aggiungendo dnsmasq<br />
<br />
DAEMONS=(... ... ... ... ... dnsmasq ... ... ...)<br />
<br />
Fatto ! Il mio DNS/DHCP è bello che pronto. Alle macchine della rete verrà fornito un indirizzo IP, il gateway, il DNS e il WINS tramite DHCP. Nello stesso momento verrà registrata sul DNS, così tutte le altre macchine potranno puntare in modo univoco alla stessa senza più preoccuparsi dell'indirizzo fisico TCP/IP.<br />
<br />
Posso visualizzare gli indirizzi IP che dnsmasq rilascia visualizzando il file:<br />
sudo cat /var/lib/misc/dnsmasq.leases<br />
<br />
Finalmente il nostro server comincia a servire a qualcosa :)</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server/DNS_dinamico_e_DHCP_(Italiano)&diff=36243Small Business Server/DNS dinamico e DHCP (Italiano)2008-01-30T17:26:23Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= DNS Dinamico e DHCP =<br />
I servizi [http://it.wikipedia.org/wiki/Domain_Name_System DNS (Domain Name System)] e [http://it.wikipedia.org/wiki/DHCP DHCP (Dynamic Host Configuration Protocol)] oramai da tempo sono diventati una soluzione obbligata in una rete locale, e considerando che i nostri client di rete saranno tutti (o quasi) Windows XP che utilizzano il DNS come protocollo primario di risoluzione dei nomi sulla rete, non possiamo assolutamente tralasciarli.<br />
Vi è mai capitata una rete di PC peer to peer con Windows XP e accesso ad internet condiviso in cui il ''browsing della rete'' locale era lentissimo ? A me parecchie volte, ed è uno dei motivi per cui non ci si dovrebbe cimentare in queste cose senza capire quello che si stà facendo. Il browsing della rete era lentissimo perchè XP prima interroga il DNS per conoscere il nome dell'host e solo dopo usa il suo simpatico broadcast o il file HOSTS. Bene, considerate che il DNS della rete era quello del provider e comincerete a capire perchè era così lento ... :D.<br />
In GNU/Linux i pacchetti che la fanno da padrone in questo campo sono [http://www.isc.org/sw/bind bind] e [http://www.isc.org/sw/dhcp dhcpd], ma data la semplice natura della nostra rete optiamo per un pacchetto più semplice che integra tutto quello che ci server: ''DNS dinamico, DHCP e Caching''. Ottenere la stessa cosa con bind e dhcpd è un po' più complicato e magari ci torneremo su.<br />
Il pacchetto che utilizzeremo si chiama [http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] e offre, ma non solo, le seguenti funzionalità :<br />
* La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.<br />
* I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.<br />
* Dnsmasq ricava i nomi dal file /etc/hosts file del firewall: se il nome della macchina locale richiesta viene trovato, si viene immediatamente indirizzati alla stessa senza il bisogno di mantenere il file hosts in ogni macchina.<br />
* Il servizio DHCP server integrato supporta DHCP leases statici e dinamici e IP ranges multipli. Le macchine configurate con DHCP vengono automaticamente inserite nel DNS, e i nomi possono essere specificati in ogni macchina o centralmente associando il nome al MAC address nel file di configurazione di dnsmasq.<br />
* Dnsmasq esegue il ''caching'' degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.<br />
* Dnsmasq supporta i records di tipo ''MX'' e ''SRV'' e può essere configurato per fornire il record MX per alcune o tutte le macchine della rete locale.<br />
== Installazione ==<br />
Il pacchetto (tanto per cambiare) lo si installa così:<br />
sudo pacman -S dnsmasq dnsutils<br />
== Configurazione ==<br />
Editiamo il file di configurazione :<br />
sudo nano /etc/dnsmasq.conf<br />
Il file è ben commentato. Impostiamo i seguenti parametri :<br />
addn-hosts=/etc/dnshosts<br />
no-hosts<br />
local=/mede.it/<br />
interface=eth1<br />
expand-hosts<br />
domain=mede.it<br />
dhcp-range=192.168.20.50,192.168.20.150,12h<br />
dhcp-option=option:router,192.168.20.1<br />
dhcp-option=44,192.168.20.1 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)<br />
dhcp-option=45,192.168.20.1 # netbios datagram distribution server<br />
dhcp-option=46,8 # netbios node type<br />
dhcp-option=47 # empty netbios scope.<br />
dhcp-option=6,192.168.20.1<br />
mx-host=archi.mede.it,50<br />
mx-target=archi.mede.it<br />
localmx<br />
log-queries<br />
log-dhcp<br />
Per vedere tutti i parametri "dhcp-options" possibili eseguite il comando :<br />
dnsmasq --help dhcp<br />
Per le spiegazioni sui singoli parametri fate riferimento alla guida in linea<br />
man dnsmasq<br />
oppure ai commenti dello stesso file di configurazione.<br />
<br />
Ora modifichiamo il nostro file /etc/resolv.conf<br />
sudo nano /etc/resolv.conf<br />
che deve contenere i DNS che il server interroga, cioè se stesso e in seconda battuta il DNS del provider di cui farà la cache (ad esempio 151.99.125.1)<br />
search mede.it<br />
nameserver 127.0.0.1<br />
nameserver 151.99.125.1<br />
Se voglio utilizzare degli indirizzi statici basta inserirli nel file /etc/dnshosts (come speficato dal parametro ''addn-hosts'') nella solita forma (senza dominio, quello lo fornisce dnsmasq) che si usa per il file /etc/hosts. Ad esempio mettiamo il nostro server principale (a cui diamo anche i nomi "mail" e "proxy" ad esempio) e un altro con IP fisso :<br />
192.168.20.1 archi mail proxy<br />
192.168.20.2 myserver<br />
dnsmasq fornirà la risoluzione di myserver o myserver.mede.it a tutte le macchine della rete.<br />
<br />
Non uso il predefinito file ''/etc/hosts'' usato da dnsmasq per evitare che il DNS si metta a risolvere anche i nomi "privati" che potrei mettere qui, tipo ad esempio ''localhost''.<br />
<br />
== Avvio del servizio ==<br />
Ora possiamo avviare il servizio:<br />
sudo /etc/rc.d/dnsmasq start<br />
e modificare la riga DAEMONS aggiungendo dnsmasq<br />
<br />
DAEMONS=(... ... ... ... ... dnsmasq ... ... ...)<br />
<br />
Fatto ! Il mio DNS/DHCP è bello che pronto. Alle macchine della rete verrà fornito un indirizzo IP, il gateway, il DNS e il WINS tramite DHCP. Nello stesso momento verrà registrata sul DNS, così tutte le altre macchine potranno puntare in modo univoco alla stessa senza più preoccuparsi dell'indirizzo fisico TCP/IP.<br />
<br />
Posso visualizzare gli indirizzi IP che dnsmasq rilascia visualizzando il file:<br />
sudo cat /var/lib/misc/dnsmasq.leases<br />
<br />
Finalmente il nostro server comincia a servire a qualcosa :)</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server/DNS_dinamico_e_DHCP_(Italiano)&diff=36242Small Business Server/DNS dinamico e DHCP (Italiano)2008-01-30T17:24:53Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= DNS Dinamico e DHCP =<br />
I servizi [http://it.wikipedia.org/wiki/Domain_Name_System DNS (Domain Name System)] e [http://it.wikipedia.org/wiki/DHCP DHCP (Dynamic Host Configuration Protocol)] oramai da tempo sono diventati una soluzione obbligata in una rete locale, e considerando che i nostri client di rete saranno tutti (o quasi) Windows XP che utilizzano il DNS come protocollo primario di risoluzione dei nomi sulla rete, non possiamo assolutamente tralasciarli.<br />
Vi è mai capitata una rete di PC peer to peer con Windows XP e accesso ad internet condiviso in cui il ''browsing della rete'' locale era lentissimo ? A me parecchie volte, ed è uno dei motivi per cui non ci si dovrebbe cimentare in queste cose senza capire quello che si stà facendo. Il browsing della rete era lentissimo perchè XP prima interroga il DNS per conoscere il nome dell'host e solo dopo usa il suo simpatico broadcast o il file HOSTS. Bene, considerate che il DNS della rete era quello del provider e comincerete a capire perchè era così lento ... :D.<br />
In GNU/Linux i pacchetti che la fanno da padrone in questo campo sono [http://www.isc.org/sw/bind bind] e [http://www.isc.org/sw/dhcp dhcpd], ma data la semplice natura della nostra rete optiamo per un pacchetto più semplice che integra tutto quello che ci server: ''DNS dinamico, DHCP e Caching''. Ottenere la stessa cosa con bind e dhcpd è un po' più complicato e magari ci torneremo su.<br />
Il pacchetto che utilizzeremo si chiama [http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] e offre, ma non solo, le seguenti funzionalità :<br />
* La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.<br />
* I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.<br />
* Dnsmasq ricava i nomi dal file /etc/hosts file del firewall: se il nome della macchina locale richiesta viene trovato, si viene immediatamente indirizzati alla stessa senza il bisogno di mantenere il file hosts in ogni macchina.<br />
* Il servizio DHCP server integrato supporta DHCP leases statici e dinamici e IP ranges multipli. Le macchine configurate con DHCP vengono automaticamente inserite nel DNS, e i nomi possono essere specificati in ogni macchina o centralmente associando il nome al MAC address nel file di configurazione di dnsmasq.<br />
* Dnsmasq esegue il ''caching'' degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.<br />
* Dnsmasq supporta i records di tipo ''MX'' e ''SRV'' e può essere configurato per fornire il record MX per alcune o tutte le macchine della rete locale.<br />
== Installazione ==<br />
Il pacchetto (tanto per cambiare) lo si installa così:<br />
sudo pacman -S dnsmasq dnsutils<br />
== Configurazione ==<br />
Editiamo il file di configurazione :<br />
sudo nano /etc/dnsmasq.conf<br />
Il file è ben commentato. Impostiamo i seguenti parametri :<br />
addn-hosts=/etc/dnshosts<br />
no-hosts<br />
local=/mede.it/<br />
interface=eth1<br />
expand-hosts<br />
domain=mede.it<br />
dhcp-range=192.168.20.50,192.168.20.150,12h<br />
dhcp-option=option:router,192.168.20.1<br />
dhcp-option=44,192.168.20.1 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)<br />
dhcp-option=45,192.168.20.1 # netbios datagram distribution server<br />
dhcp-option=46,8 # netbios node type<br />
dhcp-option=47 # empty netbios scope.<br />
dhcp-option=6,192.168.20.1<br />
mx-host=archi.mede.it,50<br />
mx-target=archi.mede.it<br />
localmx<br />
log-queries<br />
log-dhcp<br />
Per vedere tutti i parametri "dhcp-options" possibili eseguite il comando :<br />
dnsmasq --help dhcp<br />
Per le spiegazioni sui singoli parametri fate riferimento alla guida in linea<br />
man dnsmasq<br />
oppure ai commenti dello stesso file di configurazione.<br />
<br />
Ora modifichiamo il nostro file /etc/resolv.conf<br />
sudo nano /etc/resolv.conf<br />
che deve contenere i DNS che il server interroga, cioè se stesso e in seconda battuta il DNS del provider di cui farà la cache (ad esempio 151.99.125.1)<br />
search mede.it<br />
nameserver 127.0.0.1<br />
nameserver 151.99.125.1<br />
Se voglio utilizzare degli indirizzi statici basta inserirli nel file /etc/dnshosts (come speficato dal parametro ''addn-hosts'') nella solita forma (senza dominio, quello lo fornisce dnsmasq) che si usa per il file /etc/hosts. Ad esempio mettiamo il nostro server principale e un altro con IP fisso :<br />
192.168.20.1 archi<br />
192.168.20.2 myserver<br />
dnsmasq fornirà la risoluzione di myserver o myserver.mede.it a tutte le macchine della rete.<br />
<br />
Non uso il predefinito file ''/etc/hosts'' usato da dnsmasq per evitare che il DNS si metta a risolvere anche i nomi "privati" che potrei mettere qui, tipo ad esempio ''localhost''.<br />
<br />
== Avvio del servizio ==<br />
Ora possiamo avviare il servizio:<br />
sudo /etc/rc.d/dnsmasq start<br />
e modificare la riga DAEMONS aggiungendo dnsmasq<br />
<br />
DAEMONS=(... ... ... ... ... dnsmasq ... ... ...)<br />
<br />
Fatto ! Il mio DNS/DHCP è bello che pronto. Alle macchine della rete verrà fornito un indirizzo IP, il gateway, il DNS e il WINS tramite DHCP. Nello stesso momento verrà registrata sul DNS, così tutte le altre macchine potranno puntare in modo univoco alla stessa senza più preoccuparsi dell'indirizzo fisico TCP/IP.<br />
<br />
Posso visualizzare gli indirizzi IP che dnsmasq rilascia visualizzando il file:<br />
sudo cat /var/lib/misc/dnsmasq.leases<br />
<br />
Finalmente il nostro server comincia a servire a qualcosa :)</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server/DNS_dinamico_e_DHCP_(Italiano)&diff=36241Small Business Server/DNS dinamico e DHCP (Italiano)2008-01-30T17:22:15Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= DNS Dinamico e DHCP =<br />
I servizi [http://it.wikipedia.org/wiki/Domain_Name_System DNS (Domain Name System)] e [http://it.wikipedia.org/wiki/DHCP DHCP (Dynamic Host Configuration Protocol)] oramai da tempo sono diventati una soluzione obbligata in una rete locale, e considerando che i nostri client di rete saranno tutti (o quasi) Windows XP che utilizzano il DNS come protocollo primario di risoluzione dei nomi sulla rete, non possiamo assolutamente tralasciarli.<br />
Vi è mai capitata una rete di PC peer to peer con Windows XP e accesso ad internet condiviso in cui il ''browsing della rete'' locale era lentissimo ? A me parecchie volte, ed è uno dei motivi per cui non ci si dovrebbe cimentare in queste cose senza capire quello che si stà facendo. Il browsing della rete era lentissimo perchè XP prima interroga il DNS per conoscere il nome dell'host e solo dopo usa il suo simpatico broadcast o il file HOSTS. Bene, considerate che il DNS della rete era quello del provider e comincerete a capire perchè era così lento ... :D.<br />
In GNU/Linux i pacchetti che la fanno da padrone in questo campo sono [http://www.isc.org/sw/bind bind] e [http://www.isc.org/sw/dhcp dhcpd], ma data la semplice natura della nostra rete optiamo per un pacchetto più semplice che integra tutto quello che ci server: ''DNS dinamico, DHCP e Caching''. Ottenere la stessa cosa con bind e dhcpd è un po' più complicato e magari ci torneremo su.<br />
Il pacchetto che utilizzeremo si chiama [http://www.thekelleys.org.uk/dnsmasq/doc.html dnsmasq] e offre, ma non solo, le seguenti funzionalità :<br />
* La configurazione del DNS di macchine "dietro" al firewall è semplice e non dipende dai DNS del provider.<br />
* I client che interrogano il DNS quando, ad esempio, il collegamento internet non è disponibile ricevono immediatamente il timeout, senza inutili attese.<br />
* Dnsmasq ricava i nomi dal file /etc/hosts file del firewall: se il nome della macchina locale richiesta viene trovato, si viene immediatamente indirizzati alla stessa senza il bisogno di mantenere il file hosts in ogni macchina.<br />
* Il servizio DHCP server integrato supporta DHCP leases statici e dinamici e IP ranges multipli. Le macchine configurate con DHCP vengono automaticamente inserite nel DNS, e i nomi possono essere specificati in ogni macchina o centralmente associando il nome al MAC address nel file di configurazione di dnsmasq.<br />
* Dnsmasq esegue il ''caching'' degli indirizzi internet (A records e AAAA records e PTR records), aumentando le performance della rete.<br />
* Dnsmasq supporta i records di tipo ''MX'' e ''SRV'' e può essere configurato per fornire il record MX per alcune o tutte le macchine della rete locale.<br />
== Installazione ==<br />
Il pacchetto (tanto per cambiare) lo si installa così:<br />
sudo pacman -S dnsmasq dnsutils<br />
== Configurazione ==<br />
Editiamo il file di configurazione :<br />
sudo nano /etc/dnsmasq.conf<br />
Il file è ben commentato. Impostiamo i seguenti parametri :<br />
addn-hosts=/etc/dnshosts<br />
no-hosts<br />
local=/mede.it/<br />
interface=eth1<br />
expand-hosts<br />
domain=mede.it<br />
dhcp-range=192.168.20.50,192.168.20.150,12h<br />
dhcp-option=option:router,192.168.20.1<br />
dhcp-option=44,192.168.20.1 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)<br />
dhcp-option=45,192.168.20.1 # netbios datagram distribution server<br />
dhcp-option=46,8 # netbios node type<br />
dhcp-option=47 # empty netbios scope.<br />
dhcp-option=6,192.168.20.1<br />
mx-host=archi.mede.it,50<br />
mx-target=archi.mede.it<br />
localmx<br />
log-queries<br />
log-dhcp<br />
Per vedere tutti i parametri "dhcp-options" possibili eseguite il comando :<br />
dnsmasq --help dhcp<br />
Per le spiegazioni sui singoli parametri fate riferimento alla guida in linea<br />
man dnsmasq<br />
oppure ai commenti dello stesso file di configurazione.<br />
<br />
Ora modifichiamo il nostro file /etc/resolv.conf<br />
sudo nano /etc/resolv.conf<br />
che deve contenere i DNS che il server interroga, cioè se stesso e in seconda battuta il DNS del provider di cui farà la cache (ad esempio 151.99.125.1)<br />
search mede.it<br />
nameserver 127.0.0.1<br />
nameserver 151.99.125.1<br />
Se voglio utilizzare degli indirizzi statici basta inserirli nel file /etc/dnshosts (come speficato dal parametro ''addn-hosts'') nella solita forma (senza dominio, quello lo fornisce dnsmasq) che si usa per il file /etc/hosts. Ad esempio per un altro server con IP fisso :<br />
192.168.20.2 myserver<br />
dnsmasq fornirà la risoluzione di myserver o myserver.mede.it a tutte le macchine della rete.<br />
<br />
Non uso il predefinito file ''/etc/hosts'' usato da dnsmasq per evitare che il DNS si metta a risolvere anche i nomi "privati" che potrei mettere qui, tipo ad esempio ''localhost''.<br />
<br />
== Avvio del servizio ==<br />
Ora possiamo avviare il servizio:<br />
sudo /etc/rc.d/dnsmasq start<br />
e modificare la riga DAEMONS aggiungendo dnsmasq<br />
<br />
DAEMONS=(... ... ... ... ... dnsmasq ... ... ...)<br />
<br />
Fatto ! Il mio DNS/DHCP è bello che pronto. Alle macchine della rete verrà fornito un indirizzo IP, il gateway, il DNS e il WINS tramite DHCP. Nello stesso momento verrà registrata sul DNS, così tutte le altre macchine potranno puntare in modo univoco alla stessa senza più preoccuparsi dell'indirizzo fisico TCP/IP.<br />
<br />
Posso visualizzare gli indirizzi IP che dnsmasq rilascia visualizzando il file:<br />
sudo cat /var/lib/misc/dnsmasq.leases<br />
<br />
Finalmente il nostro server comincia a servire a qualcosa :)</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36212Small Business Server (Italiano)/Mail Server2008-01-30T15:25:50Z<p>Steno: /* Clamav */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.20.1<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcuno si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema ''spazza via da solo oltre il 95% dello spam !''.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinché lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.<br />
= Conclusioni =<br />
Abbiamo (anzi, ''ho'') penato un po' per questa parte ''Mail Server'', ma alla fine il risultato è ottimo. Certo, sarebbe auspicabile semplificare un pochino magari accorpando qualche funzionalità (specie il content filter) direttamente su Postfix dal momento che oramai praticamente tutti i server di posta fitrano i messaggi.<br />
Chissà magari un giorno qualcuno ci pensa, nel frattempo sorbiamoci stò mattone.<br />
<br />
Per la verità qualcosa esiste, e sono sicuramente il futuro in questo campo. Mi riferisco alle soluzioni di ''groupware'' che sempre più spesso vengono richieste, le quali permettono una reale collaborazione tra persone magari condividendo le cose più semplici come PIM e posta elettronica.<br />
<br />
Magari daremo un occhio a [http://www.zimbra.com/ Zimbra], ma questa è un altra storia ...</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36206Small Business Server (Italiano)/Mail Server2008-01-30T15:17:01Z<p>Steno: /* Postgrey */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.20.1<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcuno si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema ''spazza via da solo oltre il 95% dello spam !''.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.<br />
= Conclusioni =<br />
Abbiamo (anzi, ''ho'') penato un po' per questa parte ''Mail Server'', ma alla fine il risultato è ottimo. Certo, sarebbe auspicabile semplificare un pochino magari accorpando qualche funzionalità (specie il content filter) direttamente su Postfix dal momento che oramai praticamente tutti i server di posta fitrano i messaggi.<br />
Chissà magari un giorno qualcuno ci pensa, nel frattempo sorbiamoci stò mattone.<br />
<br />
Per la verità qualcosa esiste, e sono sicuramente il futuro in questo campo. Mi riferisco alle soluzioni di ''groupware'' che sempre più spesso vengono richieste, le quali permettono una reale collaborazione tra persone magari condividendo le cose più semplici come PIM e posta elettronica.<br />
<br />
Magari daremo un occhio a [http://www.zimbra.com/ Zimbra], ma questa è un altra storia ...</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36142Small Business Server (Italiano)/File Server Domain Controller2008-01-30T11:34:43Z<p>Steno: /* Concludiamo managgia ! */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia di ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36141Small Business Server (Italiano)/File Server Domain Controller2008-01-30T11:33:28Z<p>Steno: /* Comandi Samba */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36140Small Business Server (Italiano)/File Server Domain Controller2008-01-30T11:32:41Z<p>Steno: /* Quota */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Per installare le utility di gestione usate :<br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=36139Small Business Server (Italiano)/File Server Domain Controller2008-01-30T11:32:01Z<p>Steno: /* Quota */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''.<br />
<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36136Small Business Server (Italiano)/Mail Server2008-01-30T10:55:31Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.20.1<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcuno si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.<br />
= Conclusioni =<br />
Abbiamo (anzi, ''ho'') penato un po' per questa parte ''Mail Server'', ma alla fine il risultato è ottimo. Certo, sarebbe auspicabile semplificare un pochino magari accorpando qualche funzionalità (specie il content filter) direttamente su Postfix dal momento che oramai praticamente tutti i server di posta fitrano i messaggi.<br />
Chissà magari un giorno qualcuno ci pensa, nel frattempo sorbiamoci stò mattone.<br />
<br />
Per la verità qualcosa esiste, e sono sicuramente il futuro in questo campo. Mi riferisco alle soluzioni di ''groupware'' che sempre più spesso vengono richieste, le quali permettono una reale collaborazione tra persone magari condividendo le cose più semplici come PIM e posta elettronica.<br />
<br />
Magari daremo un occhio a [http://www.zimbra.com/ Zimbra], ma questa è un altra storia ...</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36134Small Business Server (Italiano)/Mail Server2008-01-30T10:51:10Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcuno si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.<br />
= Conclusioni =<br />
Abbiamo (anzi, ''ho'') penato un po' per questa parte ''Mail Server'', ma alla fine il risultato è ottimo. Certo, sarebbe auspicabile semplificare un pochino magari accorpando qualche funzionalità (specie il content filter) direttamente su Postfix dal momento che oramai praticamente tutti i server di posta fitrano i messaggi.<br />
Chissà magari un giorno qualcuno ci pensa, nel frattempo sorbiamoci stò mattone.<br />
<br />
Per la verità qualcosa esiste, e sono sicuramente il futuro in questo campo. Mi riferisco alle soluzioni di ''groupware'' che sempre più spesso vengono richieste, le quali permettono una reale collaborazione tra persone magari condividendo le cose più semplici come PIM e posta elettronica.<br />
<br />
Magari daremo un occhio a [http://www.zimbra.com/ Zimbra], ma questa è un altra storia ...</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36133Small Business Server (Italiano)/Mail Server2008-01-30T10:49:17Z<p>Steno: /* Filtraggio della posta */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcuno si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36132Small Business Server (Italiano)/Mail Server2008-01-30T10:48:47Z<p>Steno: /* Filtraggio della posta */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Abbiamo visto come addirittura il nostro ''Shorewall'' ci dà una mano con una importante regola.<br />
Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36131Small Business Server (Italiano)/Mail Server2008-01-30T10:47:42Z<p>Steno: /* Filtraggio della posta */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto prima configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36130Small Business Server (Italiano)/Mail Server2008-01-30T10:47:12Z<p>Steno: /* Filtraggio della posta */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36129Small Business Server (Italiano)/Mail Server2008-01-30T10:46:22Z<p>Steno: /* Filtraggio della posta */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Siamo felici perchè abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36128Small Business Server (Italiano)/Mail Server2008-01-30T10:43:44Z<p>Steno: /* La regola più importante */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedirla la spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis (come vedremo dopo) farà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36127Small Business Server (Italiano)/Mail Server2008-01-30T10:39:50Z<p>Steno: /* Dovecot */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server '''imap''' e '''pop3'''.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedire spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis fà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36126Small Business Server (Italiano)/Mail Server2008-01-30T10:38:48Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione base =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
== Dovecot ==<br />
''Dovecot'' è un ''Mail Delivery Agent'' progettato per garantire la sicurezza. Supporta la maggior parte dei formati di caselle di posta: a noi interessa particolarmente il formato ''Maildir'' dal momento che lo abbiamo adottato. Questa sezione espone come configurarlo come server **imap** e **pop3**.<br />
=== Configurazione ===<br />
Cominciamo con il copiarci il file di esempio di Dovecot che rappresenta un ottimo punto di partenza e apriamolo con il nostro editor:<br />
sudo cp /etc/dovecot/dovecot-example.conf /etc/dovecot/dovecot.conf<br />
sudo nano /etc/dovecot/dovecot.conf<br />
Possiamo notare che il file è bello corposo o_O, noi impostamo solo quello che ci interessa lasciando il resto invariato.<br />
Cominciamo con l'abilitare i protocolli [http://it.wikipedia.org/wiki/POP3 pop3] e [http://it.wikipedia.org/wiki/IMAP imap]<br />
protocols = imap pop3<br />
e proseguiamo con il disabilitare l'autenticazione ''ssl'' e abilitare le ''passwords'' in chiaro. Ok, non è il massimo della vita, ma la messa in sicurezza del server ve lo lascio come compito a casa:<br />
ssl_disable = yes<br />
disable_plaintext_auth = no<br />
conludiamo con il formato UIDL (Unique Mail Identifier) da usare. Impostiamo il predefinito consigliato che sembra non dare fastidio nemmeno a Outlook 2003 ;)<br />
pop3_uidl_format = %08Xu%08Xv<br />
=== Autenticazione ===<br />
Al fine di ottenere il nostro agognato ''Single Signon'' vogliamo far sì che Dovecot autentichi gli utenti utilizzando la stessa coppia utente/password utilizzata da Samba. I nostri utenti utilizzeranno sempre lo stesso account sia per il File Server che per la posta.<br />
Questo si può fare in modi diversi, qui utilizzeremo [http://it.wikipedia.org/wiki/Pluggable_authentication_modules PAM] che di "riflesso" utilizzerà LDAP per l'autenticazione. Apriamo (se lo abbiamo chiuso) il file di configurazione /etc/dovecot/dovecot.conf e aggiungiamo (o cerchiamo e modifichiamo, meglio) il seguente parametro :<br />
passdb pam {<br />
args = blocking=yes dovecot<br />
}<br />
In questo modo abbiamo detto a ''Dovecot'' di utilizzare ''PAM'' con le "regole" impostate nel file /etc/pam.d/dovecot che andiamo immediatamente a creare:<br />
sudo nano /etc/pam.d/dovecot<br />
così:<br />
#%PAM-1.0<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so nullok<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
Ora Dovecot per autenticare un utente utilizzerà PAM il quale prima chiederà a LDAP e poi utilizzerà l'utente locale unix.<br />
=== Avvio del servizio ===<br />
Non ci resta che avviare il servizio:<br />
sudo /etc/rc.d/dovecot start<br />
e metterlo nel nostro array DAEMONS in /etc/rc.conf per un avvio automatico:<br />
DAEMONS=(... ... ... ... ... dovecot ... ... ...)<br />
<br />
== Shorewall ==<br />
Mai dimenticarsi del Firewall ! Dobbiamo permettere il traffico sulle porte utilizzate da Dovecot e anche ''costringere'' gli utenti della nostra rete ad utilizzare il nostro server per spedire, altrimenti ...<br />
=== Configurazione ===<br />
Editiamo il file :<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
POP3/ACCEPT loc $FW<br />
IMAP/ACCEPT loc $FW<br />
se vogliamo scaricare la posta anche quando siamo fuori dall'azienda dobbiamo anche abilitare l'accesso dall'esterno:<br />
POP3/ACCEPT net $FW<br />
IMAP/ACCEPT net $FW<br />
=== La regola più importante ===<br />
Stiamo filtrando tutta la posta per proteggere i nostri utenti da SPAM e Virus, ma anche per evitare di essere ''bannati'' dagli altri server di posta perchè ''non "virtuosi"'', nel senso che ok, respingiamo le mail che arrivano, ma dobbiamo anche evitare di spedire spazzatura.<br />
Se gli utenti della nostra rete utilizzano il nostro server per spedire siamo a posto, Amavis fà già il suo lavoro, ma se un nostro utente ''buontempone'' (o un utente "esterno" nostro ospite) ha il suo bel account su GMail o su Yahoo o qualunque altro, e usa l'SMTP di questo Provider per spedire la posta ? Magari aggiungiamo che si è beccato un virus con il Notebook mentre navigava da casa che lo ha trasformato in un ''zombie'' alla mercè degli Spammers e abbiamo fatto la frittata: appena accende il computer collegato alla nostra rete aziendale, ZAC! inizia a spedire tonnellate di SPAM ''attraverso'' il suo provider il quale cosa vedrà come mittente della montagna di spazzatura che stà arrivando ? MA NATURALMENTE IL NOSTRO INCOLPEVOLE SERVER che stà "nattando" la rete con un unico indirizzo IP. Risultato ? 10 minuti e siamo bannati. Garantito.<br />
<br />
Come evitare questo disastro ? Con questa regola da applicare sempre su /etc/shorewall/rules :<br />
REDIRECT loc smtp tcp smtp - !85.85.85.85,192.168.40.10<br />
Dove "85.85.85.85" è l'indirizzo IP inventato (voi mettete quello vero!) pubblico del nostro server. In questo modo chiunque cerchi di "passare" attraverso il nostro server (ad eccezione di chi ci punta correttamente) utilizzando il protocollo SMTP della posta viene "girato" localmente sul server. Il nostro server ''filtra'' così il messaggio e, se passa i nostri canonici controlli, viene spedito da lui stesso. Non facciamoci scavalcare ! :D<br />
<br />
Bene. Ora non ci resta che riavviare il firewall:<br />
sudo shorewall restart<br />
== Tutto qua ? ==<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36125Small Business Server (Italiano)/Mail Server2008-01-30T10:31:49Z<p>Steno: /* Amavis */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.<br />
=== Clamav ===<br />
Amavis può utilizzare un ampio ventaglio di antivirus che comprende tutti i big commerciali del settore, noi abbiamo deciso per ''clamav'' dal momento che è open.<br />
Lo abbiamo già installato, ora configuriamo, avviamolo e impostiamo amavis-new affinhè lo utilizzi.<br />
<br />
Clamav ha due demoni, uno per la scansione (clamd) e uno per l'aggiornamento del database dei virus conosciuti (freshclam), facciamo in modo che entrambi siano attivi : <br />
sudo nano /etc/conf.d/clamav<br />
e impostiamo i valori così:<br />
START_FRESHCLAM="yes"<br />
START_CLAMD="yes"<br />
Ora modifichiamo i file di configurazione prima di clamav :<br />
sudo nano /etc/clamav/clamd.conf<br />
rimuoviamo (o commentiamo) la riga che inizia con "Example" e impostamo il parametro ''AllowSupplementaryGroups''<br />
che abilita clamd ad accedere ai file usando qualsiasi privilegio di gruppo abbia. Senza questo clamd non accede ai file usando i permessi di gruppo, limitando la scansione ai soli file leggibili da tutti.<br />
AllowSupplementaryGroups yes<br />
Ora dedichiamoci a ''freshclam'' :<br />
sudo nano /etc/clamav/freshclam.conf<br />
e rimuoviamo, come per clamd, la riga che inizia con "Example".<br />
Ora proviamo ad avviare il servizio:<br />
sudo /etc/rc.d/clamav start<br />
in questo modo dovrebbero partire sia ''ClamD'' che ''FreshClam''. Se questo è successo siete in gamba e avete dimostrato si saper usare bene il copia/incolla :D<br />
Proviamo ad aggiornare le definizioni dei virus :<br />
sudo freshclam<br />
Dovrei ottenere qualcosa del genere:<br />
ClamAV update process started at Fri Jan 25 16:14:49 2008<br />
main.cvd is up to date (version: 45, sigs: 169676, f-level: 21, builder: sven)<br />
daily.cvd is up to date (version: 5550, sigs: 25581, f-level: 21, builder: ccordes)<br />
Ok ? Ora non preoccupatevi, ogni 12 ore Freshclam si avvierà da solo.<br />
<br />
L'ultimo tassello di questa interminabile fase è la configurazione di amavis perché usi clamav. Per far questo ritorniamo al nostro ''incubo'' :<br />
sudo nano /etc/amavisd/amavisd.conf<br />
andiamo a decommentare la parte relativa a clamav (occhio al percorso del file clamd.sock):<br />
['ClamAV-clamd',<br />
\&ask_daemon, ["CONTSCAN {}\n", "/var/lib/clamav/clamd.sock"],<br />
qr/\bOK$/, qr/\bFOUND$/,<br />
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],<br />
<br />
e aggiungiamo l'utente ''clamav'' al gruppo ''amavis'':<br />
sudo gpasswd -a clamav amavis<br />
<br />
=== Avvio dei servizi ===<br />
Ufff, questa parte è stata lunghina e noiosa lo ammetto, ma che ci posso fare ?<br />
Ricordiamoci di modificare l'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... postfix postgrey spamd clamav amavisd ...)<br />
che contenga i nostri "impavidi" e proviamo con un virus di test che possiamo trovare [http://www.eicar.org/download/eicar.com qui]:<br />
wget http://www.eicar.org/download/eicar.com<br />
e inviamo una mail di prova :<br />
sendmail -f test@gmail.com admin@mede.it < eicar.com<br />
L'utente ''admin@mede.it'' (ricordiamo che ''virus@mede.it'' è un alias) dovrebbe ricevere una mail con la segnalazione del virus. Per il momento ci accontentiamo di controllare visualizzando il file contenuto /home/admin/MailDir/cur corrispondente alla mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36124Small Business Server (Italiano)/Mail Server2008-01-30T10:27:17Z<p>Steno: /* Amavis-new */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.<br />
<br />
=== Postfix ===<br />
Sì, cavolo, ancora Postfix. Dobbiamo modificare il file dove vengono definiti i suoi ''servizi'' aggiungendone uno per ''amavis'' e configurarlo affinché ne faccia uso.<br />
Modifichiamo il file '''master.cf''' (occhio, non ''main.cf''), dove, appunto, sono specificate le impostazioni dei servizi di postfix:<br />
sudo nano /etc/postfix/master.cf<br />
e aggiungiamo in fondo :<br />
## AMAVIS<br />
##<br />
amavis unix - - - - 2 smtp<br />
-o smtp_data_done_timeout=1200<br />
-o smtp_send_xforward_command=yes<br />
-o disable_dns_lookups=yes <br />
127.0.0.1:10025 inet n - - - - smtpd<br />
-o content_filter=<br />
-o smtpd_restriction_classes=<br />
-o smtpd_delay_reject=no<br />
-o smtpd_client_restrictions=permit_mynetworks,reject<br />
-o smtpd_helo_restrictions=<br />
-o smtpd_sender_restrictions=<br />
-o smtpd_recipient_restrictions=permit_mynetworks,reject<br />
-o smtpd_data_restrictions=reject_unauth_pipelining<br />
-o smtpd_end_of_data_restrictions=<br />
-o mynetworks=127.0.0.0/8<br />
-o smtpd_error_sleep_time=0<br />
-o smtpd_soft_error_limit=1001<br />
-o smtpd_hard_error_limit=1000<br />
-o smtpd_client_connection_count_limit=0<br />
-o smtpd_client_connection_rate_limit=0<br />
-o smtpd_milters=<br />
-o local_header_rewrite_clients=<br />
-o local_recipient_maps=<br />
-o relay_recipient_maps=<br />
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks<br />
<br />
I parametri sono ''una marea'' prendeteli per buoni, oppure (meglio) googolate alla ricerca di una spiegazione. Due cose però le scrivo. Cosa diavolo abbiamo fatto ? Semplice (si fà per dire) abbiamo definito due "servizi": ''amavis'' per il delivery via ''smtp'' della posta al content filter, e la porta di ''reiniezione'' (reinjection sulla 10025) dove ci aspettiamo la risposta. Facile no ? :D<br />
Lo sò, lo sò vi viene voglia di installare ''Exchange'' ...<br />
<br />
Non abbiamo finito, ricercate la riga più sù dove stà scritto "pickup" e fatela diventare così:<br />
pickup fifo n - n 60 1 pickup<br />
-o content_filter=<br />
-o receive_override_options=no_header_body_checks<br />
<br />
Questo fà si che i messaggi locali (ad esempio quelli generati dal server stesso con crond per postmaster o root o chicchessia) non vengano filtrati.<br />
<br />
Bene ora un ultimo tocco a main.cf :<br />
sudo nano /etc/postfix/main.cf<br />
in cui, ovviamente (almeno per chi non si è ancora perso), dobbiamo dire a postfix di usare il content filter alltraverso il servizio che abbiamo definito. Aggiungiamo quindi in fondo :<br />
content_filter = amavis:[127.0.0.1]:10024<br />
Ok ? Utilizziamo il servizio ''amavis'' che stà sulla interfaccia di loopback (127.0.0.1) sulla porta 10024. Questo vi dovrebbe far intuire che potremmo usare anche un altro server per il content filter, ma non perdiamoci, nella nostra ''Small Buisiness'' abbiamo un unico server ;)<br />
<br />
=== Amavis ===<br />
Bene, andiamo finalmente ad editare il nostro file-incubo che serve a configurare amavis. Perchè incubo ? Appena lo aprirete sull'editor capirete, diciamo che è un po' delicatino ...<br />
sudo nano /etc/amavisd/amavisd.conf<br />
Assicuriamoci che l'utente e il gruppo '''amavis''' siano impostati:<br />
$daemon_user = 'amavis';<br />
$daemon_group = 'amavis'; <br />
Troviamo e impostiamo la variabile '''$mydomain''' con il dominio:<br />
$mydomain = 'mede.it'; <br />
e cambiamo il nome del nostro host (deve esistere!) con la variabile '''$myhostname'''<br />
$myhostname = 'archi.mede.it'; <br />
troviamo la riga seguente e aggiungiamo il nostro dominio :<br />
@local_domains_maps = ( [".$mydomain", ".mede.it"] );<br />
Ora dobbiamo configurare la parte '''spamassassin''' di amavis-new. Questo primo fà si che tutte le mail indirizzate ai domini in '''@local_domains''' avranno specificato il punteggio spam nella header della mail, che siano spam oppure no.<br />
$sa_tag_level_deflt = undef;<br />
Questo è il punteggio "spartiacque" delle mail. In ogni mail con punteggio superiore a '''$sa_tag2_level_deflt''' sarà considerata spam, verrà aggiunto un prefisso "[SPAM] " all'oggetto e sarà inviata al destinatario.<br />
$sa_tag2_level_deflt = 5.0; <br />
Questo valore definisce il punteggio sopra cui la mail deve essere nessa in quarantena da Amavis. Definisce anche il livello sopra il quale il mittente viene avvisato (Delivery Status Notification, DSN) che il messaggio non è stato recapitato. Nessun DSN viene inviato, tuttavia, se il parametro '''$sa_dsn_cutoff_level''' è impostato ad un valore inferiore al punteggio spam (vedi dopo).<br />
Siccome noi non vogliamo per niente al mondo avvisare gli spammers che gli abbiamo "sgamato" la mail impostiamo il parametro al valore assurdo di 10000.<br />
$sa_kill_level_deflt = 10000;<br />
<br />
Fino a questo momento tutto lo spam è inviato ai nostri utenti, con il solo oggetto modificato. Tuttavia, quando definiremo la variabile '''$spam_quarantine_to''' più sotto, in effetti ognuna di queste mail sarà considerata "bisognosa di quarantena" e inviata a chi definito dal parametro con oggetto e header modificato.<br />
Questo parametro definisce il punteggio oltre al quale non siamo interessati ad inviare la notifica (DSN) al mittente. Possiamo lasciare questo valore dal momento che non siamo interessati ad inviare alcuna notifica (cambiaremo D_BOUNCE in D_DISCARD più sotto).<br />
$sa_dsn_cutoff_level = 9;<br />
Oltre questo livello la mail non viene nemmeno posta in quarantena<br />
$sa_quarantine_cutoff_level = 20; <br />
Come preannunciato, non inviamo MAI alcuna notifica ai mittenti. Tutte le mail finiscono in quarantena. Il preferisco inviare le mail ad un responsabile perchè controlli i messaggi incriminati anzichè in una directory di quarantena, i filtri non sono perfetti e si potrebbero verificare dei falsi positivi. Per fare questo definiamo i destinatari, e la directory di quarantena verrà disabilitata automaticamente:<br />
$final_virus_destiny = D_DISCARD;<br />
$final_spam_destiny = D_DISCARD;<br />
$final_banned_destiny = D_DISCARD;<br />
Gli indirizzi seguenti diventeranno, dunque, '''virus@mede.it''' e '''spam@mede.it''' e naturalmente devo ricordare di aggiungere questi destinatari sul mio server, o di "girarli" tramite alias a qualche indirizzo esistente. <br />
$virus_quarantine_to = "virus\@mydomain";<br />
$banned_quarantine_to = "spam\@$mydomain";<br />
$bad_header_quarantine_to = "spam\@$mydomain";<br />
$spam_quarantine_to = "spam\@$mydomain";<br />
Ora definiamo gli indirizzi di notifica. Questi destinatari riceveranno le notifiche sui virus trovati, per disabilitare la notifica basta commentare la riga.<br />
$virus_admin = "postmaster\@$mydomain";<br />
$banned_admin = "postmaster\@$mydomain";<br />
Non sarete mica già stufi ! Ora definiamo chi debba essere il mittente delle notifiche :<br />
$mailfrom_notify_admin = "postmaster\@$mydomain";<br />
$mailfrom_notify_recip = "postmaster\@$mydomain";<br />
$mailfrom_notify_spamadmin = "postmaster\@$mydomain";<br />
$hdrfrom_notify_sender = "amavisd-new <postmaster\@$mydomain>";<br />
e per ultima la stringa che deve essere anteposta all' oggetto della mail che consideriamo SPAM :<br />
$sa_spam_subject_tag = '[SPAM] ';<br />
Ora le mail arriveranno, se SPAM, con l'oggetto modificato che include questa stringa.<br />
<br />
Noiosa questa parte vero ? Almeno per me lo è stata, forse sono particolarmente allergico a questo file di configurazione che sembra (e probabilmente lo è) un sorgente scritto in perl. Veramente difficoltoso districarsi tra il marasma di opzioni, forse si potrebbe far meglio, ma l'importante è che faccia il suo dovere, e su questo non ci sono dubbi.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36123Small Business Server (Italiano)/Mail Server2008-01-30T10:23:19Z<p>Steno: /* Amavis-new */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
Configuriamo il sistema per utilizzare ''amavis-new'', occhio al file di configurazione dello stesso: '''UN VERO INCUBO''', quindi non addormentatevi sulla tastiera e magari salvate l'originale che se sbagliate qualche virgoletta o altro non funziona più un tubo ... O_o. Iniziermo con la parte ''Postfix'' e con qualla ''Spamassassin'', per conludere, poi, con quella relativa a ''Clamav''<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36122Small Business Server (Italiano)/Mail Server2008-01-30T10:20:47Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.<br />
<br />
== Amavis-new ==<br />
Abbiamo finito con le protezioni ? Neanche per sogno! Dobbiamo ancora gestire/segare il 5% dello spam che sfugge a PostFix+Postgrey, ma sopratutto dobbiamo aiutare i nostri poveri client windows nella loro titanica lotta a spyware e virus...<br />
=== Content Filter con Amavis-new ===<br />
Per questa configurazione sono state scelte delle applicazioni note per il buon livello di sicurezza che offrono e per la facilità con la quale possono essere modificati i propri file di configurazione. Come oramai abbiamo capito, per impostazione predefinita Postfix si mette in ascolto sulla porta 25 per la posta in ingresso. Quando arriva un nuovo messaggio di posta, dopo i suoi canonici controlli restrittivi (compreso Postgrey) il server lo inoltra' ad ''amavisd-new'' sulla porta 10024. Amavisd-new, successivamente, controlla il messaggio attraverso vari filtri e lo restituisce a Postfix sulla porta 10025; infine, il messaggio viene inviato alla mailbox del destinatario.<br />
Complicato vero ? Più da scrivere che da fare :)<br />
=== Un caporale con due soldati === <br />
Cos'e' ''Amavis-new'' ? '''Amavisd-new''' è un framework per il filtraggio di contenuti che utilizza applicazioni di supporto per il riconoscimento di virus e spam. Il nostro ''caporale filtratore'' utilizzerà due ''soldati'' per la sua campagna d'armi: [http://www.clamav.net/ ClamAV] per il filtraggio dei virus e [http://spamassassin.apache.org/ Spamassassin] per quello dello spam. Spamassassin, a sua volta, può poggiarsi su applicazioni di livello inferiore, come ad esempio [http://razor.sourceforge.net/ Vipul's Razor] e [http://www.rhyolite.com/anti-spam/dcc/ DCC] (non trattati in questa guida). <br />
Rispetto ad altre tecnologie di controllo dello spam (come gli ''RBL'', dall'inglese ''Real-time Blackhole List'', termine con il quale si indicano impropriamente le tecnologie ''DNSBL'', o di ''DNS blacklist'', che consistono nella pubblicazione, da parte di un sito Internet, di una lista di indirizzi IP che, per varie ragioni, ma principalmente spam, dovrebbero essere bloccati), Spamassassin non valida un dato messaggio email in base ad un singolo test. Questo programma, invece, esegue una lista di controlli, sia interni, sia usando delle applicazioni esterne, per calcolare un punteggio da assegnare ad ogni messaggio di posta. Questo punteggio è determinato in base a: <br />
* [http://it.wikipedia.org/wiki/Filtro_bayesiano Filtro Bayesiano]<br />
* Regole statiche basate su espressioni regolari<br />
* Reti distribuite e collaborative (RBL, Razor, Pyzor, DCC)<br />
In base al punteggio (configurabile) raggiunto, la mail sarà rifiutata o accettata.<br />
<br />
Quando al caporal Amavisd viene segnalato che la mail contiene virus o spam può fare le seguenti cose:<br />
<br />
* ''''PASS'''' : Il destinatario riceve la mail<br />
* ''''DISCARD'''': Il destinatario non riceve la mail. Il mittente non riceve alcuna notifica del fallimento della spedizione, il messaggio viene posto in quarantena se abbiamo deciso di abilitare questa funzionalità:<br />
* ''''BOUNCE'''': Il destinatario non riceve la mail. Il mittente riceve una notifica che la spedizione è fallita. Nessuna notifica, però, viene inviata se la mail contiene un virus e il mittente viene identificato come "fake", falso.<br />
* ''''REJECT'''': Il destinatario non riceve la mail. Il mittente dovrebbe ricevere una notifica che la spedizione è fallita dal nostro MTA (Postfix).<br />
<br />
La differenza sostanziale tra BOUNCE e REJECT è su chi prepara questa DSN (Delivery Status Notification). con REJECT è il nostro MTA (Postfix) che la prepara e la spedisce, con BOUNCE è Amavis che lo fà (generalmente questa contiene maggiori informazioni). Tuttavia Postfix non supporta la funzionalità REJECT, quindi per noi i parametri validi sono PASS, DISCARD e BOUNCE.<br />
<br />
In Amavis, queste opzioni di chiamano '''D_PASS''', '''D_DISCARD''' e '''D_BOUNCE''' e sono configurate con i parametri nel file '''/etc/amavisd/amavisd.conf''' :<br />
* '''$final_spam_destiny'''<br />
* '''$final_virus_destiny'''<br />
* '''$final_banned_destiny'''<br />
* '''$final_bad_header_destiny'''<br />
<br />
Nella nostra configurazione imposteremo amavis in modo che spam e virus siano cestinati (D_DISCARD), e siccome non disabiliteremo la quarantena, le mail spazzatura finiranno lì. Se volessimo disabilitare la quarantena le mail sarebbero buttate e perse.<br />
<br />
Ancora qualche appunto sulla quarantena. Amavis può porre le mail in quarantena quando trova spam/virus in una specifica directory oppure può inviarla ad un altro inidirizzo email perchè venga "spulciata" da un operatore umano che deciderà il destino della "presunta" spazzatura. Quindi, in pratica, potremmo ad esempio indirizzare tutta lo spam a spam@mede.it e i virus a virus@mede.it, oppure in alternativa salvarla il una directory del nostro server. Amavis permette di specificare la directory per la quarantena con il parametro '''$QUARANTINEDIR'''. Tuttavia è possibile scegliere cartelle diverse per lo spam e per i virus.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36120Small Business Server (Italiano)/Mail Server2008-01-30T10:06:44Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.<br />
== Postgrey ==<br />
Precedentemente in Postfix abbiamo impostato la direttiva ''check_policy_service'' per utilizzare un anche un servizio esterno per le restrizioni. In questo caso vogliamo usare ''Postgrey'' che implementa il graylisting. Cos'e' il graylisting ? Molti avranno sicuramente sentito parlare di ''whitelist'' (la lista dei buoni) e ''blacklist'' (la lista dei cattivi). Con Postgrey si implementa un livello intermedio tra i due, detto appunto ''greylist'' (che fantasia :)).<br />
<br />
Questo sistema sfrutta un concetto molto semplice: visto l'elevato numero di mail che gli spammers inviano, raramente tentano più di una volta l'invio della posta ad un destinatario. <br />
Con Postgrey il vostro server sfrutta questo fatto respingendo temporaneamente tutte le email provenienti da mittenti sconosciuti segnalando loro che la casella di posta del destinatario non è momentaneamente disponibile e mettendosi in ascolto per il secondo tentativo che un server "ufficiale" fà sempre.<br />
<br />
Semplice, efficace ed ingegnoso, non servono filtri bayesiani o altre diavolerie e, ve lo garantisco, per il momento questo sistema //spazza via da solo oltre il 95% dello spam !//.<br />
<br />
Più sotto vedremo in dettaglio il funzionamento.<br />
=== Configurazione ===<br />
La configurazione base di Postgrey è molto semplice. Anzi, praticamente nulla. Nelle ''smtpd_recipient_restrictions'' di Postfix abbiamo già impostato:<br />
check_policy_service inet:127.0.0.1:10030<br />
E siamo già a posto, possiamo avviare il servizio per metterlo in funzione<br />
sudo /etc/rc.d/postgrey start<br />
e inserirlo nell'array di avvio in ''/etc/rc.conf'' prima (anche se forse non è importante l'ordine) di postfix :<br />
DAEMONS=(... ... ... ... ... postgrey postfix ... ... ...)<br />
Ulteriori configurazioni per Postgrey possono essere fatte editando il file dei default del servizio postgrey<br />
sudo nano /etc/conf.d/postgrey<br />
di particolare interesse possono essere i due parametri :<br />
* ''--delay'' : definisce per quanti secondi in messaggio viene messo in graylist. Di default 300 secondi.<br />
* ''--max-age'' : definisce per quanti giorni un mittente che ha già in passato superato la verifica rimane nella whitelist generata da postgrey. Finchè sono qui verranno in futuro accettati senza verifica. Di default 30 giorni.<br />
Per variare questi parametri bisogna metterli nella variabile POSTGREY_OPTS, e riavviare il servizio.<br />
Ad esempio, per portare il ''delay'' a 180 secondi e il ''max age'' a 60 giorni :<br />
POSTGREY_OPTS="--delay=180 --max-age=60"<br />
<br />
Postgrey memorizza i suoi dati in formato Berkley DB nella cartella :<br />
/var/spool/postfix/postgrey<br />
Putroppo pare non ci siano comandi per gestire il database o per visualizzare la greylist. Se qualcuno vuole smentirmi è bene accetto.<br />
<br />
Possiamo personalizzare le whilelist editando il file dove vengono identificati i domini da non filtrare con greylist : <br />
sudo nano /etc/postfix/postgrey_whitelist_clients<br />
Oppure i destinatari da non filtrare :<br />
/etc/postfix/postgrey_whitelist_recipients<br />
<br />
=== Il giochino di Postgrey ===<br />
Con la configurazione di default vediamo a grandi linee cosa succede quando a Postgrey viene chiesta la verifica di una mail da un utente fino ad ora sconosciuto :<br />
# Postgrey rifiuta la mail e Postfix comunica che la mailbox dell'utente non è al momento disponibile<br />
# Postgrey memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella greylist<br />
# Al successivo tentativo del server mittente se non è trascorso il tempo di ''delay'' (300 secondi), postgrey continua a rifiutare la mail. Questo per evitare i rinvii troppo veloci operati dagli spammers.<br />
# Se al successivo reinvio il tempo di ''delay'' è trascorso postgrey accetta la mail e memorizza la terna indirizzo IP dell'host sorgente, email del mittente, email del destinatario nella sua ''whitelist'' per ''max age'' tempo (30 giorni)<br />
Come vediamo la ''"terna"'' rimane nella white list di default per 30 giorni, in questo modo chi ci invia regolarmente email non viene più " ritardato" da postgrey ma accettato subito.<br />
<br />
=== Controindicazioni ? ===<br />
Bhe, a parte un ritardo di 5 minuti la prima volta che qualcuno ci scrive sinceramente non ne vedo. Ok, il sistema si appesantisce perchè ogni nuovo messaggio deve essere inviato due volte, ma credetemi che i benefici sono enormi. Ho un semplice caso in cui con Postgrey i messaggi di spam sono passati da circa 8.000 al giorno a qualche decina.<br />
<br />
Godiamoci il ''greylisting'' finchè funziona, temo che se verrà implementato su larga scala (credo che i grossi provider con alto volume di traffico difficilmente lo faranno) gli spammers cominceranno ad uscire con delle contromisure...<br />
<br />
Una guerra infinita.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36117Small Business Server (Italiano)/Mail Server2008-01-30T10:01:57Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.<br />
= Filtraggio della posta = <br />
Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: ''Spam''. Qualche mail conterrà pure ''virus'' e ''malware'', e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una ''autentica epidemia''. '''Un server di posta non protetto ha breve vita''', presto saremo ''bannati'' come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è ''nostro compito'', dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.<br />
<br />
Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo ''Postgrey'' che implementa il ''graylisting'', ''Amavis-new'' che esplora le vostre mail e invoca altri pacchetti quali ''Spamassassin'' per proteggere il vostro server dallo spam e ''ClamAV'' per la scansione antivirus. Addirittura il nostro ''Shorewall'' ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme. <br />
<br />
Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).<br />
<br />
Iniziamo con Postfix.<br />
<br />
== Postfix ==<br />
Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:<br />
sudo nano /etc/postfix/main.cf<br />
Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando ''smtpd_delay_reject = yes'', mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :<br />
smtpd_delay_reject = yes<br />
Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :<br />
smtpd_helo_required = yes<br />
Ora impostiamo una serie di ''restrizioni'' da applicare. A chi non supera queste... ''"bye bye"'' prima ancora di entrare. <br />
<br />
=== Restrizioni nei comandi HELO o EHLO ===<br />
Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.<br />
* ''permit_mynetworks'': accetta le connessioni da qualsiasi mail server listato nel parametro ''mynetworks'' di main.cf<br />
* ''reject_invalid_hostname'': rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)<br />
* ''permit'': alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.<br />
smtpd_helo_restrictions =<br />
permit_mynetworks,<br />
reject_invalid_hostname,<br />
reject_non_fqdn_hostname,<br />
permit<br />
<br />
=== Restrizioni a cui sono soggetti i server remoti per i comandi inviati ===<br />
* ''reject_unauth_pipelining'' : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.<br />
* ''permit'' : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.<br />
smtpd_data_restrictions =<br />
reject_unauth_pipelining,<br />
permit<br />
<br />
=== Restrizioni sui mittenti delle mail che il server riceve ===<br />
Viene usato il comando ''SMTP MAIL FROM'' per identificarli :<br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_non_fqdn_sender'' : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.<br />
* ''reject_unknown_sender_domain'' : rifiuta le mail che provengono da domini sconosciuti<br />
* ''permit'' : vedi sopra <br />
smtpd_sender_restrictions =<br />
permit_mynetworks,<br />
reject_non_fqdn_sender,<br />
reject_unknown_sender_domain,<br />
permit<br />
<br />
=== Restrizioni nei destinatari finali delle mail che il nostro server riceve ===<br />
Sono identificati usando il comando ''SMTP RCPT TO'' :<br />
* ''reject_unverified_recipient'' : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione. <br />
* ''permit_mynetworks'' : vedi sopra<br />
* ''reject_unknown_recipient_domain'' : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido<br />
* ''reject_unauth_destination'' : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.<br />
* ''check_policy_service'' : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso '''inet:127.0.0.1:10030''' passa la palla a ''Postgrey'' per implementare le gray list. Lo vedremo più avanti.<br />
* ''permit'' : vedi sopra.<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo. <br />
<br />
=== Test delle restrizioni ===<br />
Postfix fornisce ''vagonate'' di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.<br />
==== soft_bounce ====<br />
Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file '''/etc/postfix/main.cf''', è lo stesso) e riavviamo postfix:<br />
sudo postconf -e "soft_bounce = yes"<br />
sudo /etc/rc.d/postfix restart<br />
<br />
''N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : '''sudo postfix reload''' e le nuove impostazioni saranno operative.''<br />
<br />
Quando impostato a '''yes''', le ''hard reject responses'' (5xx) sono convertite in ''soft reject responses'' (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo. <br />
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.<br />
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.<br />
==== warn_if_reject ====<br />
Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un '''warning''' nel log.<br />
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.<br />
<br />
Ad esempio :<br />
smtpd_recipient_restrictions =<br />
reject_unverified_recipient,<br />
permit_mynetworks,<br />
warn_if_reject reject_invalid_hostname,<br />
reject_unknown_recipient_domain,<br />
reject_unauth_destination,<br />
check_policy_service inet:127.0.0.1:10030<br />
permit<br />
<br />
Notate il ''warn_if_reject'' che precede la mia regola ''reject_invalid_hostname'': se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un '''warning''' e accetta la mail lo stesso.<br />
<br />
Riavviamo Postfix e controlliamo non ci siano errori:<br />
sudo /etc/rc.d/postfix restart<br />
<br />
Ottimo! Il primo passo è stato compiuto, solo server ''apparentemente'' ufficiali ci possono inviare mail.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36115Small Business Server (Italiano)/Mail Server2008-01-30T09:50:18Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.<br />
<br />
= Configurazione =<br />
== Postfix ==<br />
Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio ''Postfix'' il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...<br />
<br />
[http://www.postfix.org Postfix] è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. <br />
In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. <br />
Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). <br />
Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.<br />
<br />
=== Parametri di configurazione ===<br />
Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file '' /etc/postfix/main.cf '', iniziamo da qui :<br />
sudo nano /etc/postfix/main.cf<br />
con questi parametri :<br />
queue_directory = /var/spool/postfix<br />
command_directory = /usr/sbin<br />
daemon_directory = /usr/lib/postfix<br />
mail_owner = postfix<br />
<br />
==== myhostname e mydomain ====<br />
Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da '' gethostbyname() '', il secondo il nome del dominio :<br />
myhostname = archi.mede.it<br />
mydomain = mede.it<br />
<br />
==== myorigin ====<br />
Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain. <br />
myorigin = $mydomain<br />
<br />
==== mydestination ====<br />
La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.<br />
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain<br />
<br />
==== mynetworks ====<br />
Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. <br />
Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un [http://en.wikipedia.org/wiki/Open_relay open relay], ovvero un server attraverso cui '' chiunque '' può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...).<br />
Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:<br />
mynetworks = 127.0.0.0/8, 192.168.20.0/24<br />
==== masquerade_domains ====<br />
Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il [http://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name] dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama ''mybox'' e il mio utente ''steno'' chi riceve le mail che spedisco vede il mittente nella forma '' steno@mybox.mede.it'' che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro ''masquerade_domains''. Postfix sostitusce la parte domain con quanto specificato qui.<br />
masquerade_domains = mede.it<br />
Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente ''steno@mede.it''.<br />
==== alias_maps e alias_database ====<br />
Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente<br />
alias_maps = hash:/etc/postfix/aliases<br />
alias_database = $alias_maps<br />
==== mailbox_size_limit ====<br />
Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.<br />
mailbox_size_limit = 0<br />
==== home_mailbox ====<br />
Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato ''mbox'' e salvato un file con il nome utente in ''/var/spool/mail''. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in ''/home/nomeutente/Maildir''<br />
home_mailbox = Maildir/<br />
Maggiori informazioni le trovate sul sito di [http://www.postfix.org/postconf.5.html postfix].<br />
=== Testare Postfix ===<br />
Avviamo postfix per fare un test se tutto funziona regolarmente :<br />
sudo /etc/rc.d/postfix start<br />
Installiamo ''telnet'' e colleghiamoci con sulla porta 25<br />
sudo pacman -S netkit-telnet<br />
telnet localhost 25<br />
Dovrei ottenere la risposta:<br />
Trying 127.0.0.1...<br />
Connected to archi.<br />
Escape character is '^]'.<br />
220 archi.mede.it ESMTP Postfix<br />
Ora iniziamo il colloquio :<br />
helo 192.168.20.10<br />
Postfix risponde:<br />
250 archi.mede.it<br />
Continuiamo a scrivere (dopo ogni riga premete invio) :<br />
mail from:test@gmail.com<br />
rcpt to: admin@mede.it<br />
data<br />
subject: Mail di prova<br />
Salve, ti mando una mail di prova<br />
.<br />
Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:<br />
250 2.0.0 Ok: queued as 13BF410D898D<br />
Il numerone ''13BF410D898D'' è un numero random che cambia ogni volta.<br />
Ora digitando:<br />
quit<br />
Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se ''admin'' ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :<br />
sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi<br />
E' la mail che avete appena inviato ? :)<br />
=== Aliases ===<br />
Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente ''admin'' anzichè al predefinito (che abbiamo disabilitato) ''root''.<br />
sudo nano /etc/postfix/aliases<br />
All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :<br />
#Person who should get root's mail. Don't receive mail as root!<br />
#root: you<br />
Togliamo il commento dalla seconda riga a mettiamo ''admin'':<br />
root: admin<br />
Usciamo dall'editor e digitiamo:<br />
newaliases<br />
Ora le mail dirette a ''root'' verranno girate al nostro utente ''admin''.<br />
=== Avvio del servizio ===<br />
Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :<br />
DAEMONS=(... ... ... ... ... postfix ... ... ...)<br />
<br />
=== Tutto qua ? ===<br />
Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. <br />
Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...<br />
<br />
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36108Small Business Server (Italiano)/Mail Server2008-01-30T09:38:35Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
== Un lavoro di squadra ==<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36107Small Business Server (Italiano)/Mail Server2008-01-30T09:37:43Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
Ad un ''SBS'' che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.<br />
= Premessa =<br />
Il ''mail server'' che andremo ad implementare è un mail server ''ufficiale''. Questo significa che :<br />
# Il nostro ipotetico dominio ''mede.it'' deve essere pubblicamente registrato<br />
# L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip ''fisso''<br />
# Il ''maintainer'' del nostro dominio, se gestisce anche il DNS "pubblico" di ''mede.t'', deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di ''mede.it'' siamo noi.<br />
Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità ''relay''. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo ''andarci a prendere la posta in arrivo dal server del provider'' se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.<br />
++ Un lavoro di squadra<br />
La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ''ping pong'' dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da ''virus'' e ''spam'' se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di ''qualche giorno'' prima di venire ''bannati'' dagli altri.<br />
Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a ''6 voci'', dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. <br />
Vediamo quali sono i nostri interpreti:<br />
#'''Postfix''' : Il nostro MTA che implementa il server SMTP della nostra azienda<br />
#'''Postgrey''' : Servizio che implementa il ''greylisting''<br />
#'''Clamav''' : L'antivirus usato da amavis-new per scanarizzare le mail<br />
#'''Spamassassin''' : Usato da amavis-new per individuare lo spam<br />
#'''Amavis-new''' : Il ''content filter'' che analizza le mail con ''Clamav'' e ''SpamAssassin''<br />
#'''Dovecot''' : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server<br />
Un bel ''coretto'' non c'è che dire ...<br />
= Installazione =<br />
Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.<br />
== Postfix ==<br />
sudo pacman -S postfix<br />
controlliamo ora che il file /etc/passwd contenga :<br />
postfix:x:73:73::/var/spool/postfix:/bin/false<br />
e che /etc/group contenga :<br />
postdrop:x:75:<br />
postfix:x:73:<br />
<br />
== Postgrey ==<br />
Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR.<br />
Prima installamo i moduli perl necessari :<br />
sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex <br />
e ora il pacchetto da AUR<br />
yaourt -S postgrey<br />
N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.<br />
<br />
== Clamav ==<br />
sudo pacman -S clamav<br />
<br />
== Spamassassin ==<br />
sudo pacman -S spamassassin<br />
<br />
== Amavis-new ==<br />
Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :<br />
sudo pacman -S make patch<br />
E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.<br />
yaourt -S amavisd-new<br />
Alla fine rientra in gioco il mio repository ''radioattivo''.<br />
pacman -Sf stenoweb/perl-file-temp<br />
Amavis vuole "espressamente" la versione 0.19 di ''perl-file-temp''. Noi siamo gentili e gliela forniamo.<br />
<br />
== Dovecot ==<br />
sudo pacman -S dovecot<br />
<br />
= Il giochino delle parti =<br />
Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee.<br />
Quando un messaggio arriva al nostro MTA succederà questo:<br />
# Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey<br />
# Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo<br />
# Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis<br />
# Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.<br />
# Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.<br />
# Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.<br />
Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena...<br />
IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/Mail_Server&diff=36099Small Business Server (Italiano)/Mail Server2008-01-30T09:29:35Z<p>Steno: New page: Category:ArchLinux Small Business Server</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35905Small Business Server (Italiano)/File Server Domain Controller2008-01-29T16:00:14Z<p>Steno: /* Concludiamo managgia ! */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux '''O'''penldap '''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35904Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:59:49Z<p>Steno: /* Concludiamo managgia ! */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare LOS ('''L'''inux'''O'''penldap'''S'''amba) amigos (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35903Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:56:20Z<p>Steno: /* setfacl & getfacl */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questa parte non è proprio specifica di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35902Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:54:25Z<p>Steno: /* ACL POSIX */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,'''acl''' 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35901Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:53:33Z<p>Steno: /* ACL POSIX */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate '''ACL POSIX'''. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35900Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:50:12Z<p>Steno: /* Gestione dei permessi */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- '''Vi fermo io, e con un esempio semplice semplice'''. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35899Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:49:20Z<p>Steno: /* Gestione dei permessi */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- 'Vi fermo io, e con un esempio semplice semplice'. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35898Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:48:49Z<p>Steno: /* setchown */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd","ftp" e "amavis" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35897Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:40:51Z<p>Steno: /* Funziona ? */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35894Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:26:25Z<p>Steno: /* OpenLDAP server */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35893Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:26:05Z<p>Steno: /* LDAP Tools */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necessaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP in un [http://www.stenoweb.it/node/55 precedente articolo], ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35892Small Business Server (Italiano)/File Server Domain Controller2008-01-29T15:25:42Z<p>Steno: /* Il repository ''radioattivo'' */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata precedentemente, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necassaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP in un [http://www.stenoweb.it/node/55 precedente articolo], ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35889Small Business Server (Italiano)/File Server Domain Controller2008-01-29T14:49:31Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata nel [http://www.stenoweb.it/node/43 primo capitolo] di questa serie, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necassaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP in un [http://www.stenoweb.it/node/55 precedente articolo], ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =<br />
Terminiamo qui la parte ''File Server''. Si potrebbe continuare per non sò quanto, ma tutto quello che potremmo dire sarebbe "Off Topic" in questa guida incentrata su ArchLinux. Tutto "il di più" sarebbe qualcosa di ''cross distro'' (sì può dire ?) ed esistono già valide guide sul web. Limitiamoci allora ad una lista di cose che potrebbero risultare utili e su cui magari sarebbe oppurtuno approfondire in modo autonomo.<br />
== Print services ==<br />
Non abbiamo minimamente parlato delle condivisioni delle stampanti. Qui si aprirebbe un altro fronte che coinvolge CUPS e la distribuzione automatica dei drivers stampante ai client Windows. Samba supporta questa funzionalità, e il posto migliore dove apprendere questa tecnica sono le guide ufficiali.<br />
Io personalmente non l'ho mai implementato non per pigrizia ma per le oramai onnipresenti stampanti con scheda di rete integrata a cui i client inviano direttamente le stampe. Tuttavia una sbirciatina non fà male.<br />
== Client grafici di amministrazione ==<br />
Abbiamo già visto come sia possibile da Windows amministrare le ''permissions'' sulle share Samba. Esistono anche delle GUI che ci permettono di gestire utenti e password in modo semplice, specie se le opzioni da settare sono un po' ''esotiche'', tipo la scadenza della password o la lista delle workstation da cui un utente può fare il logon. Ne esistono diversi, dall'ufficale [http://de.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html Samba Web Adiministration Tool (SWAT)] all' [http://lam.sourceforge.net/ LDAP Account Manager]. Possiamo usarne anche da Windows, ad esempio dal mio preferito (forse perchè fatto con Delphi ?) [http://ldapadmin.sourceforge.net/ LDAP Admin], allo [http://www.microsoft.com/downloads/details.aspx?FamilyID=C0011AB8-3178-4701-A791-EAFBA0F42DE2&displaylang=en User Manager for Domains] "ufficiale" fornito da Microsoft (non è uno scherzo) per amministrare i vari aspetti e flag.<br />
== Quota ==<br />
Altro aspetto interessante è la gestione delle ''Disk Quota'' da assegnare ad utenti e gruppi. Questo, come per le ACL Posix, è un "affare" anche del file system, oltre che di Samba con il ''vfs objects = default_quota''<br />
Dopo averli installati con <br />
sudo pacman -S quota-tools<br />
Potete trovare informazioni sulla parte file system su come amministrarli e configurarli in giro per la rete, ad esempio [http://a2.pluto.it/a2204.htm qui]. Per la parte Samba naturalmente la solita "bibbia" rappresentata dalle guide ufficiali.<br />
== Comandi Samba ==<br />
Samba viene fornito con una serie di comandi utili all'amministratore, da ''pdbedit'' per amministrare utenti e gruppi alla pletora dei comandi ''net'' disponibili. Facciamo un paio di esempi, con il comando:<br />
sudo net rpc rights list -U Administrator<br />
ottengo questo:<br />
SeMachineAccountPrivilege Add machines to domain<br />
SeTakeOwnershipPrivilege Take ownership of files or other objects<br />
SeBackupPrivilege Back up files and directories<br />
SeRestorePrivilege Restore files and directories<br />
SeRemoteShutdownPrivilege Force shutdown from a remote system<br />
SePrintOperatorPrivilege Manage printers<br />
SeAddUsersPrivilege Add users and groups to the domain<br />
SeDiskOperatorPrivilege Manage disk shares<br />
<br />
e vedo i permessi dell'utente Administrator. Potrei voler assegnare una "right" di amministrazione a qualche altro utente, e questo si fà con i comandi ''net rpc right''.<br />
Se digito :<br />
sudo pdbedit -L -v Antonio<br />
Ottengo<br />
Unix username: antonio<br />
NT username: antonio<br />
Account Flags: [UX ]<br />
User SID: S-1-5-21-1491279793-2809991009-2777690449-11012<br />
Primary Group SID: S-1-5-21-1491279793-2809991009-2777690449-513<br />
Full Name: antonio<br />
Home Directory:<br />
HomeDir Drive: K:<br />
Logon Script: antonio.bat<br />
Profile Path:<br />
Domain: MEDE<br />
Account desc:<br />
Workstations:<br />
Munged dial:<br />
Logon time: 0<br />
Logoff time: never<br />
Kickoff time: never<br />
Password last set: 0<br />
Password can change: 0<br />
Password must change: 0<br />
Last bad password : 0<br />
Bad password count : 0<br />
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
che sono tutte le impostazioni assegnate all'utente ''Antonio'' e che posso variare con ''pdbedit''. Gran parte di queste le posso anche amministrare con il nostro ''netusermod'', ma sicuramente il comando standard è più completo essendo parte di Samba.<br />
<br />
I comandi ''man net'' e ''man pdbedit'' forniscono le informazioni di cui si ha bisogno.<br />
== Lock sui file ==<br />
Stiamo amministrando un server con dei file condivisi, quindi il lock dei file è cosa vitale. In genere non ci sono problemi, Samba "standard" ci risolve già gran parte dei problemi, ma in alcuni casi (tipo il "solito" file access mdb condiviso) dovete metter manina voi.<br />
Vi scontrerete ad esempio con il concetto di ''"Opportunistic Locking"'' inventato da Microsoft per aumentare le performance in rete, ma che in alcuni casi con Samba non produce gli effetti desiderati. Niente paura, vanno solo gestiti.<br />
Anche in questo caso (son stufo di scriverlo) vi rimando alla guida ufficiale.<br />
== Sicurezza ==<br />
Non abbiamo nemmeno discusso della messa in sicurezza del colloquio tra Samba e OpenLDAP che adesso avviene in chiaro. Essendo entrambi i servizi nella stessa macchina magari il problema e minimo, ma se cominciate ad avere più server Samba che "puntano" allo stesso server LDAP o più server LDAP replicati magari in remoto tra sedi diverse è una opzione da prendere in seria considerazione.<br />
== Client Linux ==<br />
O perbacco ! E i client Linux ? Qualcuno comincerà ad arrivare...<br />
Per le autenticazioni LDAP e le share non credo sia un problema (anche se devo ogni volta digitare utente e password), ma il logon ad un dominio Microsoft ? Ho visto solo due distro che lo fanno: SLED e la sua controparte libera OpenSUSE. Quindi è possibile ma mi sento proprio impreparato sull'argomento. Fatemi sapere voi magari.<br />
== Concludiamo managgia ! ==<br />
Dite la verità: ''Pensavate fosse più semplice''. O almeno è quello che ho pensato io la prima volta che mi sono imbattuto in questi argomenti. Spero di aver acceso l'interesse di qualcuno che abbia la voglia ''studiare'', la rete offre tutto di cui si ha bisogno. E credetemi, se imparate bene ad amministrare ''LOS (**L**inux**O**penldap**S**amba) amigos'' (senza dimenticare DNS/DHCP) domani (quasi) potete installare una rete con Windows, perchè i concetti li conoscete (anche più in profondità di altri), dovete solo scoprire dove fare "click" con il mouse (uaaaah, questa forse è grossa ma suona bene :)).<br />
<br />
Ma che bello era fare "Pulsante destro sulla cartella -> convidi con nome -> ok " ?</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35886Small Business Server (Italiano)/File Server Domain Controller2008-01-29T14:44:31Z<p>Steno: /* Configurazione */</p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata nel [http://www.stenoweb.it/node/43 primo capitolo] di questa serie, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necassaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione autenticazione LDAP =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP in un [http://www.stenoweb.it/node/55 precedente articolo], ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente.<br />
<br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =</div>Stenohttps://wiki.archlinux.org/index.php?title=Small_Business_Server_(Italiano)/File_Server_Domain_Controller&diff=35885Small Business Server (Italiano)/File Server Domain Controller2008-01-29T14:43:43Z<p>Steno: </p>
<hr />
<div>[[Category:ArchLinux Small Business Server]]<br />
= Introduzione =<br />
Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.<br />
== Samba ==<br />
Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione '''Samba'''che mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop.<br />
Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux.<br />
Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.<br />
== Cos’e’ questa guida ? ==<br />
Ricordo ancora che questa guida ''NON è una guida completa a Samba e OpenLDAP'', oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio.<br />
Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul [http://www.samba.org sito] è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.<br />
== Samba Server è meglio di Windows Server ? ==<br />
Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server.<br />
Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo.<br />
Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.<br />
== Ma allora perché usare Samba ? ==<br />
I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :<br />
* Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.<br />
* Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.<br />
* Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.<br />
* Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.<br />
== E’ più facile usare/amministrare Windows o Linux/Samba ? ==<br />
Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una ''PESSIMA IDEA''.<br />
E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari.<br />
Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.<br />
== Sostituisco i miei server Windows con Linux/Samba ? ==<br />
Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione.<br />
Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.<br />
<br />
N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.<br />
<br />
Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .<br />
= Installazione =<br />
Cominciamo con la configurazione del nostro file server ''domain controller'' basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.<br />
== Operazioni preliminari ==<br />
In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le ''rules'' aggiuntive opportune. Quindi:<br />
sudo /etc/rc.d/shorewall stop<br />
In più abilitiamo momentaneamente **tutti** i protocolli :<br />
sudo nano /etc/hosts.allow<br />
e aggiungiamo la riga <br />
all: ALL : allow<br />
Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.<br />
== Il repository ''radioattivo'' ==<br />
Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script ''perl'' e delle librerie dello stesso, avrei potuto usare ''CPAN'' ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e ''radioattivo'' repository personale con quello che ci serve.<br />
Creare un repository con Arch è veramente una operazione banale con il comando ''repo-add'', un po' più complicati sono i ''PKGBUILD''. Di grande aiuto mi è stata l'utility ''cpan4pacman'' installata nel [http://www.stenoweb.it/node/43 primo capitolo] di questa serie, che mi ha creato i ''PKGBUILD'' per le librerie perl mancanti, appena un po' più complesso il pacchetto ''smbldap-tools'' che ho dovuto fare da zero (o quasi). Perchè ''radioattivo'' ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità. <br />
=== Attiviamo il repository ===<br />
sudo nano /etc/pacman.conf<br />
aggiungiamo in fondo :<br />
[stenoweb]<br />
Server = http://www.stenoweb.it/repo/i686<br />
e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo ''stenoweb'':<br />
sudo pacman -Sy<br />
Bene ! Non dovreste ottenere errori.<br />
== Installazione pacchetti ==<br />
=== Samba ===<br />
Ma come diavolo si installerà Samba ? io proverei con un:<br />
sudo pacman -S samba<br />
Funziona ! Scusate non ho resistito ...<br />
=== LDAP Tools ===<br />
E qui interviene il mio repository. Gli [http://freshmeat.net/projects/smbldap-tools LDAP Tools] sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file ''/etc/passwd e /etc/group''. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti.<br />
Iniziamo con installare le librerie perl necessarie :<br />
sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl <br />
e poi il pacchetto vero e proprio con gli scripts:<br />
sudo pacman -S smbldap-tools<br />
Gli script sono stati copiati/installati in ''/usr/local/bin'' e i file di configurazione in ''/etc/smbldap-tools''.<br />
I comandi sono nella forma (ad esempio per aggiungere un utente) :<br />
sudo /usr/local/bin/smbldap-useradd ''nomeutente''<br />
ma non provateci adesso, mancando la necassaria configurazione otterrete solo un errore.<br />
Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in ''/bin''. Il comando di prima diventerà il più semplice:<br />
sudo netuseradd ''nomeutente''<br />
Prolunghiamo la vita alle nostre tastiere! :)<br />
=== Samba LDAP Schema ===<br />
Per ultimo abbiamo bisogno del file di ''schema'' da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il ''tracciato record'' che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP.<br />
Il file ''samba.schema'' di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente.<br />
Spostiamoci nella cartella degli schemi di OpenLDAP :<br />
cd /etc/openldap/schema<br />
e scarichiamoci lo schema:<br />
sudo wget http://www.stenoweb.it/repo/noarch/samba.schema<br />
= Configurazione =<br />
Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.<br />
== OpenLDAP server ==<br />
Abbiamo già configurato in modo basilare OpenLDAP in un [http://www.stenoweb.it/node/55 precedente articolo], ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.<br />
sudo nano /etc/openldap/slapd.conf<br />
Includiamo gli schemi necessari all'inizio (nis e samba):<br />
include /etc/openldap/schema/nis.schema<br />
include /etc/openldap/schema/samba.schema<br />
Impostiamo le regole di accesso :<br />
access to dn.base=""<br />
by self write<br />
by * auth<br />
<br />
access to attrs=userPassword,sambaNTPassword,sambaLMPassword<br />
by dn="cn=Manager,dc=mede,dc=it" write<br />
by anonymous auth<br />
by self write<br />
by * none<br />
<br />
access to *<br />
by * read<br />
by anonymous auth<br />
<br />
Soffermiamoci su di un aspetto: il rootdn ''cn=Manager,dc=mede,dc=it'' ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso ''access to attrs=userPassword,sambaNTPassword,sambaLMPassword'' che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows.<br />
Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :<br />
# Indices<br />
index objectClass eq<br />
index cn pres,sub,eq<br />
index sn pres,sub,eq<br />
index uid pres,sub,eq<br />
index displayName pres,sub,eq<br />
index uidNumber eq<br />
index gidNumber eq<br />
index memberUID eq<br />
index sambaSID eq<br />
index sambaPrimaryGroupSID eq<br />
index sambaDomainName eq<br />
index default sub<br />
Per attivare le nuove impostazioni riavviamo il servizio:<br />
sudo /etc/rc.d/slapd restart<br />
Il nostro albero è pronto.<br />
== LDAP Tools ==<br />
Gli ''LDAP tools'' sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :<br />
sudo nano /etc/samba/smb.conf<br />
e inseriamo :<br />
[global]<br />
unix charset = LOCALE<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
enable privileges = yes<br />
guest account = guest<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
security = user<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
<br />
Come si può notare al momento (ricordo che ''il servizio samba non è stato ancora avviato'') forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di ''Domain Controller'' (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue ''manpage'' :).<br />
Come secondo passo prendiamo nota del [http://en.wikipedia.org/wiki/Security_Identifier SID] del nostro server:<br />
sudo net getlocalsid<br />
dovrei ottenere qualcosa del tipo:<br />
SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449<br />
Ora editiamo i file di configirazione dei smbldap-tools:<br />
nano /etc/smbldap-tools/smbldap.conf<br />
e scorrendo i parametri impostamoli così:<br />
#Il SID ricavato con il comando precedente<br />
SID="S-1-5-21-1491279793-2809991009-2777690449"<br />
sambaDomain="MEDE"<br />
suffix="dc=mede,dc=it"<br />
hash_encrypt="MD5"<br />
defaultMaxPasswordAge="180"<br />
userSmbHome=""<br />
userProfile=""<br />
userHomeDrive="K:"<br />
userScript="%U.bat"<br />
mailDomain="mede.it"<br />
Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:<br />
sudo nano /etc/smbldap-tools/smbldap_bind.conf<br />
e facciamo diventare così:<br />
slaveDN="cn=Manager,dc=mede,dc=it"<br />
slavePw="archimede"<br />
masterDN="cn=Manager,dc=mede,dc=it"<br />
masterPw="archimede"<br />
Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in ''/etc/openldap/slapd.conf'' in formato MD5.<br />
Finito questo proteggiamo i file da occhi indiscreti:<br />
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf<br />
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf<br />
Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:<br />
sudo smbpasswd -w archimede<br />
se ottenete una risposta del tipo:<br />
Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb<br />
Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.<br />
== Popolare LDAP ==<br />
Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.<br />
Gli ''ldap tools'' forniscono un comodo comando per svolgere questa operazione: ''smbldap-populate''. Lanciamolo così con questi parametri:<br />
sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000<br />
al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :<br />
Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)<br />
(using builtin directory structure)<br />
<br />
adding new entry: dc=mede,dc=it<br />
adding new entry: ou=Users,dc=mede,dc=it<br />
adding new entry: ou=Groups,dc=mede,dc=it<br />
adding new entry: ou=Computers,dc=mede,dc=it<br />
adding new entry: ou=Idmap,dc=mede,dc=it<br />
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it<br />
adding new entry: uid=guest,ou=Users,dc=mede,dc=it<br />
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it<br />
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it<br />
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it<br />
<br />
Please provide a password for the domain Administrator:<br />
Changing UNIX and samba passwords for Administrator<br />
New password:<br />
Retype new password: <br />
<br />
Come possiamo notare ''smbldap-populate'' ha creato utenti e gruppi predefiniti in una installazione di windows server.<br />
Per vedere se tutto funziona proviamo a creare un utente ''user1'':<br />
sudo netuseradd -a -m user1<br />
e diamogli una password :<br />
sudo netpasswd user1<br />
ora controlliamo se l'utente c'e':<br />
sudo getent passwd<br />
Dovrei ottenere la lista degli utenti tra cui :<br />
Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false<br />
guest:x:5000:514:guest:/dev/null:/bin/false<br />
user1:x:5001:513:System User:/home/user1:/bin/bash<br />
per le opzioni complete digitiamo ''netuseradd'' senza parametri e diamo una occhiata. Nell'esempio il parametro ''-a'' crea sia l'utente unix che samba e ''-m'' crea la home (/home/user1) dell'utente. <br />
= Pianificazione condivisioni =<br />
E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.<br />
== Gruppi ==<br />
Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):<br />
{| border="1"<br />
|+<br />
! Gruppo !! Descrizione <br />
|-<br />
| commerciale || utenti ufficio commerciale ||<br />
|-<br />
| tecnico || utenti ufficio tecnico ||<br />
|-<br />
| Domain Users || gruppo che contiene tutti gli utenti ||<br />
|}<br />
<br />
''Domain Users'' è già stato creato con ''smbldap-populate''. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.<br />
=== Creiamo gli altri gruppi ===<br />
sudo netgroupadd -a Commerciale<br />
sudo netgroupadd -a Tecnico<br />
=== Creiamo gli utenti ===<br />
sudo netuseradd -a -m commerciale1<br />
sudo netpasswd commerciale1<br />
sudo netuseradd -a -m tecnico1<br />
sudo netpasswd tecnico1<br />
se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:<br />
sudo getent passwd<br />
Alla fine dovrei vedere gli utenti appena creati:<br />
commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash<br />
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash<br />
Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (''/bin/bash''). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:<br />
sudo netusermod -s /bin/false tecnico1 <br />
=== Assegniamo gli utenti ai gruppi ===<br />
sudo netgroupmod -m commerciale1 Commerciale<br />
sudo netgroupmod -m tecnico1 Tecnico<br />
Anche qui possiamo controllare con :<br />
sudo getent group<br />
e ottenere qualcosa del genere:<br />
Commerciale:*:5001:commerciale1<br />
Tecnico:*:5002:tecnico1<br />
I comandi ''net*'' li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.<br />
== Condivisioni ==<br />
Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in ''/samba'':<br />
{| border="1"<br />
|+<br />
! Condivisione !! Percorso !! Descrizione<br />
|-<br />
| public ||/samba/public || Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)<br />
|-<br />
| netlogon||/samba/netlogon ||Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.<br />
|-<br />
| profiles||/samba/profiles||Cartella di sistema. Mi serve se uso i Profili Roaming di windows.<br />
|-<br />
| rootdir||/samba||Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server<br />
|-<br />
| apps||/samba/apps||Cartella applicazioni. Sola lettura<br />
|-<br />
| homes||/home||Cartelle home per gli utenti. Ognuno la sua.<br />
|}<br />
<br />
=== public ===<br />
Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a ''public'' e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :<br />
{| border="1"<br />
|+<br />
| /samba/public || di proprietà di root/Administrator solo leggibile dagli altri<br />
|-<br />
| /samba/public/commerciale || Cartella per gruppo "Commerciale"<br />
|-<br />
| /samba/public/tecnico || Cartella per gruppo "Tecnico"<br />
|-<br />
| /samba/public/comune || Cartella condivisa di tutti ("Domain Users")<br />
|}<br />
Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:.<br />
Tengo a precisare che questa non è una regola ''ma una mia personale idea'' su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows.<br />
Quindi creiamo la struttura :<br />
sudo mkdir /samba/public<br />
sudo mkdir /samba/public/commerciale<br />
sudo mkdir /samba/public/tecnico<br />
sudo mkdir /samba/public/comune<br />
e sistemiamo i permessi e la proprietà :<br />
sudo chmod 770 /samba/public/commerciale<br />
sudo chgrp Commerciale /samba/public/commerciale<br />
sudo chmod 770 /samba/public/tecnico<br />
sudo chgrp Tecnico /samba/public/tecnico<br />
sudo chmod 770 /samba/public/comune<br />
sudo chgrp "Domain Users" /samba/public/comune<br />
Controlliamo cosa abbiamo combinato:<br />
ls -al /samba/public<br />
e dovrei vedere qualcosa del genere:<br />
drwxr-xr-x 5 root root 4096 17 dic 16:24 .<br />
drwxr-xr-x 7 root root 4096 12 dic 16:11 ..<br />
drwxrwx--- 2 root Commerciale 4096 17 dic 16:24 commerciale<br />
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune<br />
drwxrwx--- 2 root Tecnico 4096 17 dic 16:24 tecnico<br />
==== La ''"rogna"'' dei permessi utente ====<br />
Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono ''flaggati'' con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ...<br />
Ma non disperate ! :) Ci viene in aiuto il flag [http://en.wikipedia.org/wiki/Setuid SETUID] di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :<br />
sudo chmod g+s /samba/public/commerciale<br />
sudo chmod g+s /samba/public/tecnico<br />
sudo chmod g+s /samba/public/comune<br />
se ricontrollo ora con ''ls -al'' dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da ''rwx'' a ''rws'' che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ''ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente''. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.<br />
=== netlogon & profiles ===<br />
Queste sono due condivisioni di sistema, necessarie quando si configura un ''domain controller''. In ''netlogon'' si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in ''profiles'' ci saranno i profili utente nel caso avessimo deciso di usare i ''profili roaming'' di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono).<br />
Creiamo le certelle e diamo i permessi :<br />
sudo mkdir /samba/netlogon<br />
sudo mkdir /samba/profiles<br />
chmod 777 /samba/profiles<br />
=== rootdir ===<br />
Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella ''system'' con i ''link simbolici'' alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.<br />
sudo ln -s /home /samba/home<br />
In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti<br />
sudo mkdir /samba/system<br />
sudo ln -s /etc /samba/system/etc<br />
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap<br />
Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".<br />
=== apps ===<br />
In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:<br />
sudo mkdir /samba/apps<br />
sudo chmod 750 /samba/apps<br />
sudo chgrp "Domain Users" /samba/apps<br />
sudo chmod g+s /samba/apps<br />
=== homes ===<br />
Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.<br />
<br />
Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.<br />
= Configurazione di Samba =<br />
E' giunta l' ora del servizio ''Samba'' finalmente. Configuriamolo a dovere e avviamo il servizio. Vediamo anche una (breve) spiegazione dei parametri principali applicati al nostro ''smb.conf''.<br />
Andiamo ad editare il file di configurazione di Samba:<br />
sudo nano /etc/samba/smb.conf<br />
e vediamo cosa scriverci ...<br />
== Parametri globali ==<br />
Nella sezione [global] abbiamo i parametri generali del server, soffermiamoci solo su quelli (per me) significativi. Alla fine c'e' il file completo per un comodo copia/incolla. Per il resto rimando alla guida.<br />
Il nome del dominio:<br />
workgroup = MEDE<br />
Il nome del server :<br />
netbios name = ARCHI<br />
Samba rimane in ascolto solo sulle interfacce specificate, la eth0 che è rivolta all'esterno verso internet naturalmente non viene servita. O vogliamo dare servizi di file server al mondo ? :)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
Diciamo a Samba che il ''repository'' di utenti, gruppi e password è il server LDAP specificato.<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
Ordine con cui vengono risolti i nomi delle workstation. ''Broadcast'' per ultimo off course.<br />
name resolve order = wins host dns bcast<br />
Script richiamati da Samba quando ''da Windows'' tento le operazioni citate. Questo mi permette di usare tools windows per gestire utenti e gruppi, oltre che ad eseguire la ''join'' al dominio.<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
Script di login eseguiti dagli utenti quando si collegano. %U viene trasformata nel nome utente. Ad esempio l' utente ''tecnico1'' eseguirà (se esiste) lo script ''tecnico1.bat'' che si trova in ''netlogon''.<br />
logon script = %U.bat<br />
Non voglio i profili roaming, quindi metto a ''null'' questi parametri. Attenzione che i parametri ''userSmbHome'' e ''userProfile'' specificati in ''/etc/smbldap-tools/smbldap.conf'' hanno la precedenza su questi !<br />
logon path =<br />
logon home =<br />
Il mio server è un ''domain controller'' :)<br />
domain logons = Yes<br />
Eleggiamo il nostro server ad autorità ''maxima'', facciamolo diventare [http://en.wikipedia.org/wiki/Domain_Master_Browser master browser] per il segmento della nostra rete.<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
Il nostro server è anche server [http://en.wikipedia.org/wiki/Windows_Internet_Name_Service wins]<br />
wins support = Yes<br />
Parametri dell'albero LDAP a cui Samba si collega. In questo modo si indica a Samba dove trovare utenti, gruppi, computer e il nome utente da utilizzare per connettersi (cn=Manager). Ricordiamo che la password la abbiamo memorizzata con il comando ''smbpasswd -w '' nell'articolo precedente.<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
ldap ssl = no<br />
Il tipo di autenticazione da usare (IMPORTANTISSIMO!).<br />
security = user<br />
Ho specificato dei parametri aggiuntivi che vedete alla fine del post, lascio a voi il compito di interpretarli ;).<br />
Ora passiamo alla sezione ''condivisioni''.<br />
== Condivisioni ==<br />
Abbiamo visto nell' articolo precedente quali condivisioni andiamo a realizzare, vediamo come sono state tradotte sul file di configurazione. Non le espongo tutte, ma solo quelle che hanno qualche parametro significativo da spiegare. La versione completa del file ''smb.conf'' la trovate alla fine del post.<br />
=== public ===<br />
Nome e percorso condivisione<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
Scrivibile:<br />
writeable = yes<br />
La vedo nel ''browsing'' della rete:<br />
browseable = Yes<br />
Nascondi i file e le cartelle che l'utente non può leggere. Questo è utile, in questa condivisione un utente vedrà solo quello che gli serve anzichè chiedersi cosa ci sia "dentro" una cartella che non riesce ad aprire... :)<br />
hide unreadable = Yes<br />
Questa serie di parametri corrispondono ad una serie di tentativi per fare in modo che questa condivisione funzioni a dovere. Ora non me la sento di cambiare qualcosa. Chi lascia la vecchia strada ...<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
I ''vfs objects'' sono un utile "plugin" di Samba. In questo caso usiamo l'oggetto ''recycle'' per realizzare un ''cestino di rete''. I file eliminati non andranno eliminati immediatamente ma finiranno in una cartella nascosta ''.cestino/nomeutente''. Poi faremo uno script di ''purge'' per vuotare i cestini ogni tanto. I parametri aggiuntivi servono per dire a samba di non salvare i file temporanei e di backup e di non applicare il ''versioning'' ai file di office (creano problemi con il salvataggio automatico di quest'ultimo). <br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
=== netlogon ===<br />
Questa condivisione di "servizio" è fondamentale per la gestione degli script di logon degli utenti.<br />
Intanto la nascondiamo dal browsing della rete.<br />
browseable = No<br />
Nel momento in cui l'utente accede alla condivisione (e tutti gli utenti di un dominio lo fanno) viene eseguito ''/etc/samba/logon.pl'' a cui vengono passati dei parametri tipo il nome utente che ha richiamato lo script, il gruppo, l'orario ecc.. Cosa fà questo programmino ? Semplice, ''crea lo script di logon dell'utente "al volo"'' secondo le regole definite in ''logon.pl''. Ad esempio viene creato ''tecnico1.bat'' per l'utente ''tecnico1''. Potrei omettere questo parametro e creare a mano lo script, ma così è molto più comodo e vedremo perché. <br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
E ora vediamo come è fatto questo ''logon.pl''. <br />
sudo nano /etc/samba/logon.pl<br />
e impostiamolo così:<br />
#!/usr/bin/perl<br />
#<br />
open LOG, ">>/var/log/samba/netlogon.log";<br />
print LOG "$ARGV[3] - Utente $ARGV[0] collegato a $ARGV[2]\n";<br />
close LOG;<br />
#<br />
# Elenco utenti per share<br />
#<br />
$APPS ="-tecnico1-tecnico2-";<br />
$NOLOGON ="-administrator-";<br />
$DELMAP ="-winnt-win2k-win2k3-winxp-";<br />
$ADMIN ="administrator";<br />
#<br />
# Inizio generazione script<br />
#<br />
open LOGON, ">/samba/netlogon/$ARGV[0].bat";<br />
print LOGON "\@ECHO OFF\r\n";<br />
print LOGON "ECHO ARCHI logon script\r\n";<br />
print LOGON "ECHO.\r\n";<br />
#<br />
# Sincronizza orario con il server<br />
#<br />
print LOGON "NET TIME \\\\ARCHI /SET /YES\r\n";<br />
#<br />
# Se piattaforma PC in lista $DELMAP cancella i vecchi mappaggi<br />
#<br />
if (index($DELMAP,"-".lc($ARGV[5])."-") >=0)<br />
{<br />
print LOGON "NET USE * /DEL /YES\r\n";<br />
}<br />
#<br />
# Esci se utente in lista $NOLOGON altrimenti applica i mappaggi comuni<br />
#<br />
if (index($NOLOGON,"-".lc($ARGV[0])."-") == -1)<br />
{<br />
# Disco L: (PUBLIC)<br />
print LOGON "NET USE L: \\\\ARCHI\\public /YES\r\n";<br />
# Disco K: (HOME)<br />
print LOGON "NET USE K: \\\\ARCHI\\$ARGV[0] /YES\r\n";<br />
<br />
# Disco X: (APPS)<br />
if (index($APPS,"-".lc($ARGV[0])."-") >=0)<br />
{<br />
print LOGON "NET USE X: \\\\ARCHI\\apps /YES\r\n";<br />
}<br />
}<br />
# Chiudi il file.<br />
close LOGON;<br />
<br />
Possiamo vedere che ''condizioniamo'' la creazione dello script in base a delle variabili in testa. Ad esempio solo la lista degli utenti specificata in ''$APPS'' (tecnico1 e tecnico2 separati con "-") avranno la mappatura X:, e gli utenti listati in ''$NOLOGON'' (administrator) non avranno alcuno script. Tutto chiaro ?<br />
Questo script può essere modificato ed esteso con semplicità seguendo questo schema di esempio, e ha il pregio di semplificare la gestione degli script di logon. Voglio che anche l'utente "commerciale1" mappi la X: per \\archi\apps ? Basta aggiungerlo nella lista ''$APPS'' e la prossima volta che si collega al server avrà il suo script aggiornato "al volo". In più ho anche un file di log in ''/var/log/samba/netlogon.log'' che mi informa dell'orario di collegamento degli utenti.<br />
<br />
Wow. A volte le cose semplici sono le più importanti. Come compito a casa mi fate lo script che scrive nel log l'orario in cui si scollegano usando il parametro ''root postexec''. ;)<br />
<br />
Tengo a precisare che i parametri ''root preexec'' (e ''root postexec'' che viene eseguito allo "scollegamento") non sono una prerogativa di ''netlogon''. Possono essere usati con ''qualunque'' condivisione per eseguire "qualcosa" al momento del collegamento (e/o dello scollegamento).<br />
<br />
Ricordiamoci di rendere eseguibile lo script perl :<br />
sudo chmod 775 /etc/samba/logon.pl<br />
== smb.conf completo ==<br />
E ''dulcis in fundo'' ecco il file di configurazione completo da ''spulciare'' e studiare. Posso, ad esempio, notare che ho gestito il cestino anche sulle ''home'' e autorizzato solo i membri del gruppo "Domain Admins" ad accedere alla condivisione di "servizio" ''rootdir''.<br />
[global]<br />
workgroup = MEDE<br />
netbios name = ARCHI<br />
server string = %h PDC (%v)<br />
interfaces = eth1, lo<br />
bind interfaces only = Yes<br />
passdb backend = ldapsam:ldap://archi.mede.it<br />
enable privileges = yes<br />
log level = 0<br />
log file = /var/log/samba/%m<br />
max log size = 50<br />
smb ports = 139 445<br />
hide dot files = yes<br />
name resolve order = wins host dns bcast<br />
time server = Yes<br />
guest account = guest<br />
show add printer wizard = No<br />
add user script = /bin/netuseradd -a -m '%u'<br />
delete user script = /bin/netuserdel '%u'<br />
add group script = /bin/netgroupadd -a -p '%g'<br />
delete group script = /bin/netgroupdel '%g'<br />
add user to group script = /bin/netgroupmod -m '%u' '%g'<br />
delete user from group script = /bin/netgroupmod -x '%u' '%g'<br />
# Disabilitare quando a fare il join al dominio è un Windows NT<br />
set primary group script = /bin/netusermod -g '%g' '%u'<br />
add machine script = /bin/netuseradd -w '%u'<br />
logon script = %U.bat<br />
# Profili Roaming<br />
#logon path = \\%L\profiles\%U<br />
logon path =<br />
logon home =<br />
logon drive = K:<br />
domain logons = Yes<br />
domain master = yes<br />
preferred master = Yes<br />
os level = 65<br />
wins support = Yes<br />
# LDAP<br />
ldap suffix = dc=mede,dc=it<br />
ldap user suffix = ou=Users<br />
ldap machine suffix = ou=Computers<br />
ldap group suffix = ou=Groups<br />
ldap idmap suffix = ou=Idmap<br />
ldap admin dn = cn=Manager,dc=mede,dc=it<br />
idmap backend = ldap:ldap://archi.mede.it<br />
idmap uid = 10000-20000<br />
idmap gid = 10000-20000<br />
ldap passwd sync = Yes<br />
#ldap ssl = start tls<br />
ldap ssl = no<br />
map acl inherit = Yes<br />
#printing = cups<br />
lock directory = /var/lock/samba<br />
winbind use default domain = yes<br />
winbind enum users = yes<br />
winbind enum groups = yes<br />
security = user<br />
template shell = /bin/false<br />
[public]<br />
comment = "L: - Cartella Pubblica Utenti"<br />
path = /samba/public<br />
writeable = yes<br />
browseable = Yes<br />
hide unreadable = Yes<br />
directory mask = 0775<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
#inherit acls = yes<br />
#inherit permissions = yes<br />
vfs objects = recycle<br />
recycle:repository = .cestino/%U<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[homes]<br />
comment = "K: - Cartella privata di %U, %u"<br />
writeable = yes<br />
create mask = 0700<br />
directory mask = 0775<br />
browseable = No<br />
force user = %U<br />
vfs objects = recycle<br />
recycle:repository = .cestino<br />
recycle:keeptree = yes<br />
recycle:touch = yes<br />
recycle:versions= yes<br />
recycle:exclude = *.tmp *.bak ~$*<br />
recycle:exclude_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppte_dir = /tmp /temp /cache<br />
recycle:noversions = *.doc *.xls *.ppt<br />
[rootdir]<br />
comment = Cartella globale, solo per amministrazione e backup<br />
path = /samba<br />
writeable = yes<br />
browseable = yes<br />
directory mask = 0770<br />
create mask = 0775<br />
force create mode = 0775<br />
force directory mode = 6775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
admin users = Administrator<br />
valid users = "@Domain Admins"<br />
force create mode = 0644<br />
force directory mode = 6775<br />
[apps]<br />
comment = "Y: - Applicazioni"<br />
path = /samba/apps<br />
writeable = yes<br />
browseable = Yes<br />
directory mask = 0770<br />
create mask = 0775<br />
security mask = 0777<br />
force security mode = 0<br />
directory security mask = 0777<br />
force directory security mode = 0<br />
hide unreadable = Yes<br />
force create mode = 0775<br />
force directory mode = 6775<br />
[netlogon]<br />
comment = Network Logon Service<br />
path = /samba/netlogon<br />
guest ok = Yes<br />
locking = No<br />
browseable = No<br />
root preexec = /etc/samba/logon.pl "%U" "%G" "%L" "%T" "%m" "%a"<br />
#root postexec = /etc/samba/logoff.pl "%U" "%G" "%L" "%T"<br />
[profiles]<br />
comment = Profile Share<br />
path = /samba/profiles<br />
writeable = yes<br />
profile acls = Yes<br />
browsable = No<br />
<br />
= Avvio del servizio =<br />
Quasi me ne dimenticavo :)<br />
sudo /etc/rc.d/samba start<br />
e mettiamolo nella lista dei nostri deamons:<br />
DAEMONS=(... ... ... ... ... samba ... ... ...) <br />
= Join al dominio e scripts di manutenzione =<br />
Ora che finalmente abbiamo avviato Samba, facciamo la ''join'' del server al nostro dominio nuovo fiammante, controlliamo che funzioni e creiamo un paio di script bash utili per la manutenzione del sistema<br />
== Join al dominio ==<br />
Per prima cosa dobbiamo unire il nostro server al dominio (che traduzione orrenda: diciamo che dobbiamo fare la ''join''...), con il comando :<br />
sudo net rpc join -S ARCHI -U Administrator<br />
dopo aver digitato la password dovreste vedere il messaggio:<br />
Joined domain MEDE.<br />
In questa fase Samba ha creato l'account workstation per il vostro server nel suo backend LDAP nel formato ''nomemacchina$''. Andiamo a vedere se è vero con il comando ''getent'':<br />
sudo getent passwd<br />
Alla fine dovrei vedere il mio server :<br />
archi$:*:5004:515:Computer:/dev/null:/bin/false<br />
Ottimo. Passiamo oltre.<br />
== Funziona ? ==<br />
Controlliamo subito. Facciamolo con i comandi di Samba, così siamo sicuri che sia lui a rispondere alle nostre richeste:<br />
sudo pdbedit -L<br />
Dovrebbe mostrarmi la lista degli utenti, tipo questa:<br />
Administrator:0:Administrator<br />
guest:5000:guest<br />
commerciale1:5001:commerciale1<br />
tecnico1:5002:tecnico1<br />
archi$:5004:Computer<br />
e ora controlliamo anche le condivisioni :<br />
sudo smbclient -L localhost -U administrator<br />
e dopo la password dovrei vedere una cosa del tipo :<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Sharename Type Comment<br />
--------- ---- -------<br />
IPC$ IPC IPC Service (archi PDC (3.0.28))<br />
print$ Disk Printer Drivers<br />
apps Disk Y: - Applicazioni<br />
rootdir Disk Cartella globale, solo per amministrazione e backup<br />
public Disk L: - Cartella Pubblica Utenti<br />
Administrator Disk K: - Cartella privata di administrator, Administrator<br />
Domain=[MEDE] OS=[Unix] Server=[Samba 3.0.28]<br />
Server Comment<br />
--------- -------<br />
ARCHI archi PDC (3.0.28)<br />
Workgroup Master<br />
--------- -------<br />
MEDE ARCHI<br />
Wow! Ce l'abbiamo fatta, il nostro domain controller è pronto ad accogliere le vostre workstation Windows (e Linux off course) tra le sue forti braccia.<br />
== Scripts di manutenzione ==<br />
=== purge ===<br />
Predentemente abbiamo abilitato il plugin Samba per gestire il ''cestino'' del server: ogni utente che cancella i file in realtà li sposta nella cartella ''.cestino/nomeutente'' che abbiamo definito. Capirete anche voi che non possiamo lasciarli lì per sempre ma abbiamo bisogno di ''purgare'' i cestini di tanto in tanto per mantenere il sistema pulito dalla spazzatura.<br />
Chi ha conosciuto ''Novell Netware'' non può non ricordare il comando ''purge'' che svolgeva egregiamente questa funzione, purtroppo qui non abbiamo niente di simile, e dobbiamo arrangiarci con bash. Tranquilli, ci ho già pensato io qualche anno fa, niente di eclatante ma svolge la sua funzione in modo preciso. Creiamo il file:<br />
sudo nano /bin/purge<br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# purge<br />
# Vuota il cestino degli utenti e di sistema<br />
# by steno 2005-2007<br />
#<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: purge {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`; <br />
else<br />
DIR=$1;<br />
fi;<br />
fi;<br />
#<br />
# Vuota il cestino privato degli utenti<br />
#<br />
for user in $DIR; do<br />
if [ -e /home/$user/.cestino ];<br />
then<br />
X="`(cd /home/$user/.cestino ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino utente <$user>";<br />
rm /home/$user/.cestino/* -r;<br />
else<br />
echo "Cestino personale utente <$user> vuoto";<br />
fi;<br />
fi;<br />
done;<br />
#<br />
# Vuota il cestino globale di "public"<br />
#<br />
DIR=`ls /samba/public/.cestino -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
for user in $DIR; do<br />
X="`(cd /samba/public/.cestino/$user ; echo *)`";<br />
if [ ! "$X" = "*" ] ; then<br />
echo "Elimina file dal cestino globale utente <$user>" ;<br />
rm /samba/public/.cestino/$user -R;<br />
else<br />
echo "Cestino globale utente <$user> vuoto";<br />
fi <br />
done;<br />
Come vedete possiamo "purgare" tutto con il parametro ''all'' o limitarci ad uno specifico utente. Lo script è poi suddiviso in due parti, la prima si occupa del cestino di ogni singola ''home/user'', la seconda del cestino della share principale ''public''.<br />
Rendiamo eseguibile lo script:<br />
sudo chmod 755 /bin/purge<br />
e creiamo il Cestino globale dando i permessi corretti alla cartella:<br />
sudo mkdir /samba/public/.cestino<br />
sudo chmod 770 /samba/public/.cestino <br />
sudo chgrp "Domain Users" /samba/public/.cestino<br />
Ora basta digitare ''purge all'' da shell per avviare le pulizie di primavera :), ''purge tecnico1'' per il cestino del solo utente ''tecnico1''. Prendiamo anche in considerazione la possibilità di schedularlo con ''crontab'' per avviarlo automaticamente al "calar della notte". <br />
=== setchown ===<br />
Questo script si usa meno del precedente, ma in alcuni casi è molto utile. Cosa fà lo script ? Semplice, ''corregge i permessi su file e directory delle home degli utenti''. A volte magari, come amministratore, si ripristinano, copiano o spostano dei file da una cartella di un utente ad un altro e poi dobbiamo manualmente lavorare di ''chown'' e ''chmod'' per sistemare il tutto. Lo script ''setchown'' lo fa da solo spazzolando tutte le home degli utenti (con i parametro ''all'') correggendo permessi e proprietà. Creiamo il file:<br />
sudo nano /bin/setchown <br />
e inseriamoci quanto segue:<br />
#!/bin/bash<br />
# setchown<br />
# Setta il proprietario della home dir e dei file allo user<br />
# escludi dal processo le home listate nella var "exclude"<br />
exclude="httpd ftp amavis";<br />
# Controlla i parametri<br />
if [ $# = 0 ]<br />
then<br />
echo "uso: setchown {all|<username>}"<br />
exit;<br />
else<br />
if [ $1 = 'all' ]<br />
then<br />
DIR=`ls /home -F | awk '/\/$/ {sub( /\/$/,""); print}'`;<br />
else<br />
DIR=$1;<br />
fi;<br />
fi; <br />
#<br />
for user in $DIR; do<br />
mask=${exclude#*$user};<br />
if [ "$mask" = "$exclude" ]<br />
then<br />
chown $user /home/$user -R<br />
chmod 700 /home/$user<br />
echo "Permessi corretti in /home/$user";<br />
fi<br />
done<br />
<br />
Anche qui vediamo che possiamo digitare ''setchown all'' per tutte le home oppure ''setchown tecnico1'' per la singola home.<br />
Non dimentichiamoci di rendere eseguibile lo script:<br />
sudo chmod 755 /bin/setchown<br />
Tenete presente anche la variabile ''$exclude'' nello script, in cui dobbiamo inserire la lista delle cartelle in home da non processare. Ho messo "httpd" e "ftp" che Archlinux ha la malaugurata idea di creare in home (ma ''/var'' faceva schifo ?).<br />
== Firewall ==<br />
Ora possiamo riabilitare il firewall. Prima modifichiamo il file ''rules'':<br />
sudo nano /etc/shorewall/rules<br />
e aggiungiamo le nuove regole:<br />
SMB/ACCEPT $FW loc<br />
SMB/ACCEPT loc $FW<br />
Per riavviare il servizio usiamo il comando ''shorewall'', così vediamo se abbiamo commesso sbagli:<br />
sudo shorewall start<br />
== Abbiamo finito ? ==<br />
In teoria sì, in pratica no. Per domini semplici da pochi utenti potreste essere già ok, ma la realtà è ben diversa dalla teoria e nel proseguo scoprirete uno dei perché con un semplice esempio.<br />
= Gestione dei permessi =<br />
Seeee, abbiamo il nostro nuovo ''scintillante'' domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- **Vi fermo io, e con un esempio semplice semplice.** Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ... ci sia di mezzo il vostro zelante capo ufficio tecnico. <br />
<br />
Raccontiamo una storia.<br />
<br />
== Gli utenti Windows ==<br />
Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il ''motore'' del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.<br />
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con ''diritti di accesso e permessi'' su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con ''Administrator'' o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che ''pure io'' in Windows lavoro come ''Administrator'').<br />
<br />
Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? " <br />
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...<br />
== Un caso pratico ==<br />
Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.<br />
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:<br />
<br />
''"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."''<br />
<br />
Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.<br />
== Mettamoci la lavoro ==<br />
Allora, noi abbiamo la condivisione ''"public"'' (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:<br />
sudo netuseradd -a -m Antonio<br />
sudo netpasswd Antonio<br />
sudo netuseradd -a -m Giovanni<br />
sudo netpasswd Giovanni <br />
sudo netgroupadd -a Prodotti<br />
sudo netgroupmod -m Antonio,Giovanni Prodotti<br />
sudo mkdir /samba/public/prodotti<br />
sudo chmod 770 /samba/public/prodotti<br />
sudo chgrp Prodotti /samba/public/prodotti<br />
sudo chmod g+s /samba/public/prodotti<br />
Bene. Ora ''Antonio'' e ''Giovanni'' hanno a disposizione ''L:\prodotti'' su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.<br />
Andiamo avanti. Per ''Lucia'' e ''Maria'' creiamo un gruppo "Prodotti-RO" (Read Only):<br />
sudo netuseradd -a -m Lucia<br />
sudo netpasswd Lucia<br />
sudo netuseradd -a -m Maria<br />
sudo netpasswd Maria<br />
sudo netgroupadd -a Prodotti-RO<br />
sudo netgroupmod -m Lucia,Maria Prodotti-RO<br />
E adesso ? Cosa faccio ?<br />
# ''Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci.'' Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.<br />
# ''Uso i parametri di smb.conf "Read List" e "Write List".'' Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.<br />
# ''Faccio una share "prodotti" apposita slegata da "public".''Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio ''smb.conf'' diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.<br />
Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.<br />
== Samba non c'entra ==<br />
E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.<br />
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.<br />
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.<br />
== ACL POSIX ==<br />
La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate **ACL POSIX**. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.<br />
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.<br />
Editiamo il nostro /etc/fstab :<br />
sudo nano /etc/fstab<br />
e abilitamole specificando il flag "acl" nel mount del nostro file system:<br />
/dev/sda3 / ext3 defaults,**acl** 0 1<br />
Riavviamo e siamo a posto. Abbiamo le estensioni attivate.<br />
==== setfacl & getfacl ====<br />
Questi sono i nostri due nuovi amici, ''setfacl'' per settare i permessi estesi e ''getfacl'' per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio [http://www.suse.de/~agruen/acl/linux-acls/online/ qui], oppure [http://a2.pluto.it/a2218.htm qui] se preferite la lingua italiana.<br />
Questa è la nostra situazione:<br />
drwxrws--- 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Visualizziamola con :<br />
sudo getfacl /samba/public/prodotti<br />
e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :<br />
# file: samba/public/prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
other::---<br />
Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":<br />
sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti<br />
Visualizziamo di nuovo:<br />
sudo getfacl /samba/public/prodotti<br />
e stavolta ottengo questo:<br />
# file: prodotti<br />
# owner: root<br />
# group: Prodotti<br />
user::rwx<br />
group::rwx<br />
group:Prodotti-RO:r-x<br />
mask::rwx<br />
other::---<br />
default:user::rwx<br />
default:group::rwx<br />
default:group:Prodotti-RO:r-x<br />
default:mask::rwx<br />
default:other::---<br />
<br />
Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).<br />
Se adesso riguardiamo la situazione con ''ls -al'' vedo questo :<br />
drwxrws---+ 2 root Prodotti 4096 21 dic 15:46 prodotti<br />
Il segno '+' alla fine indica che nella cartella ''prodotti'' sono attive le estensioni acl posix.<br />
<br />
Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ... <br />
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.<br />
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente): 'possiamo gestire e cambiare i permessi sulle cartelle anche direttamente da Windows''.<br />
Basta collegarsi con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando ''setfacl'' corrispondente.<br />
<br />
Ma voi preferite la shell vero ?<br />
= Conclusioni =</div>Steno