Mia mamma usa Linux! » Samba

Samba: installazione di un fileserver gestito con gruppi di accesso locali

Raoul Scarazzini — Fri, 31 Dec 2010 16:10:57 +0000

Questo articolo illustra come ottenere un’installazione coerente di un fileserver Linux basato su SAMBA, che amministri l’accesso alle condivisioni attraverso utenti che appartengano a gruppi di sistema, gestiti in una forma riconoscibile.
Gli utenti, pur essendo a tutti gli effetti parte del sistema, avranno permessi di accesso unicamente attraverso il protocollo CIFS, gestito dalle macchine Microsoft Windows.

Installazione di SAMBA

La procedura descritta fa riferimento al sistema operativo Ubuntu Server 10.4, ed all’ultima release stabile disponibile in esso per il progetto libero SAMBA, la versione 3.4.7.
L’installazione per Ubuntu ed i sistemi Debian, può essere effettuata come di consueto:

# apt-get install samba

mentre nei sistemi che fanno uso di rpm e di yum il comando sarà invece:

# yum install samba

Prima di effettuare qualsiasi operazione è bene salvare il file di configurazione originale di SAMBA:

# cd /etc/samba
# mv smb.conf smb.conf.org

nel corso dell’articolo partiremo da un file completamente vuoto, per sottolineare come sia possibile impostare pochi parametri per essere operativi nel minor tempo possibile.

Configurazione di SAMBA (impostazioni globali)

Le configurazioni descritte fanno hanno come presupposto il fatto che l’utente con cui si sta operando all’interno del sistema sia “root”. Attraverso l’editor preferito sarà possibile creare un nuovo file smb.conf:

# sudo su -
# vi /etc/samba/smb.conf

All’interno del quale dovranno essere impostati i seguenti parametri:

[global]
   security = user
   workgroup = NETWORK.LOCAL
   server string = %h server (Samba, Ubuntu) 
 
   wins support = yes 
   dns proxy = no 
 
   log file = /var/log/samba/log.%m 
   max log size = 1000 
   syslog = 0 
 
   encrypt passwords = true 
   passdb backend = tdbsam
 
   directory mask = 2770 
   create mask = 0660

Le configurazioni indicano che il server è di tipo standalone (security = user), ossia non collegato a sistemi di autenticazione centralizzati. Il server è parte del gruppo di lavoro “NETWORK.LOCAL” (opzione workgroup, che andrà modificata a seconda delle impostazioni relative propria rete Microsoft Windows) e funzionerà da server WINS (wins support = yes) in modo da gestire la risoluzione dei nomi Microsoft Windows per la rete, ma non controllerà però i nomi effettuando query sul server dns di sistema (dns proxy = no).
Il sistema registrerà un log per ciascuna macchina che si collegherà (log file = /var/log/samba/log.%m), tale log non potrà eccedere un megabyte di grandezza (max log size = 1000). Inoltre nessuna informazione verrà registrata nel file /var/log/syslog (syslog = 0), il file di log generale relativo al sistema. Tutte le informazioni relative all’esecuzione del demone saranno reperibili all’interno del file /var/log/samba/log.smbd.
Il sistema di autenticazione cripterà le password (encrypt passwords) ed utilizzerà il backend tdbsam (opzione passdb backend), ossia il database locale.
Le ultime due opzioni indicate definiscono la maschera attraverso la quale verranno create le directory (directory mask = 2770) ed i file (create mask = 0660). Le directory verranno quindi create con permessi di lettura, scrittura ed esecuzione per il proprietario ed il gruppo, mentre per tutti gli altri saranno inaccessibili. I file verranno creati con i medesimi permessi ad eccezione dell’esecuzione.
Particolarità aggiuntiva della modalità di creazione delle cartelle è quella di possedere il bit setgid (http://it.wikipedia.org/wiki/Setuid_e_setgid) che impone l’appartenenza al gruppo della cartella padre per tutti i file e le cartelle create al suo interno. Questo significa che chiunque appartenga al gruppo della cartella padre potrà creare file e cartelle al suo interno, tali file e cartelle apparterranno al gruppo della cartella padre. In questo modo i permessi specifici di accesso per i gruppi definiti nelle cartelle governeranno la totalità degli accessi.

Configurazione di un gruppo

Ciascun gruppo di accesso verrà nominato in questo modo:

# groupadd samba_rwx_Amministrazione

Il criterio con cui i gruppi vengono creati e nominati è ottenibile scomponendo il nome attraverso i caratteri “_” (underscore), dove “samba” indica che il gruppo è inerente al servizio samba, “rwx” indica il tipo di accesso che può essere appunto “rwx” (permessi di lettura e scrittura) o “rx” (sola lettura), mentre “Amministrazione” indica il nome della condivisione a cui il gruppo si riferisce.

Aggiunta di un’utenza

Ogni utenza creata nel sistema che farà riferimento al servizio samba, avrà come gruppo primario samba, con identificativo “999″, creato con il seguente comando:

# groupadd -g 999 samba

In questo modo, la separazione degli ambiti operativi sarà oltre che configurata nel sistema, anche ben visibile.
Per aggiungere un’utenza al sistema i passi da compiere sono quindi i seguenti:

Lanciare il comando:
```
# useradd -g samba -s /bin/false -d -c "Utente di test" user1
```
In cui user1 rappresenta il nome attraverso il quale l’utente dovrà accedere alle condivisioni. A user1 viene assegnato il gruppo primario “samba” (-g samba), una shell di login nulla in modo che non possa mai effettuare il login nel sistema (-s /bin/false) ed una breve descrizione dell’utenza (-d, generalmente nome e cognome, oppure un indicativo della funzione svolta).
L’utente creato va poi aggiunto al database locale SAMBA, attraverso questo comando:
```
# smbpasswd -a user1
```
indicando per due volte la password scelta, che può essere anche omessa nel caso in cui lo si decida (è sempre consigliabile inserirne una).
L’utente va quindi aggiunto ad uno dei gruppi disponibili. Aggiungere utenti al gruppo è possibile con il seguente comando:
```
# adduser user1 samba_rwx_Amministrazione
```

Per controllare quali utenti appartengono al gruppo è sufficiente digitare il seguente comando:

# cat /etc/group | grep "samba_rwx_Amministrazione"
samba_rwx_Amministrazione:user1,user2,user3

Mentre per controllare un singolo utente a quali gruppi appartiene, il comando sarà invece:

# groups user1
user1 : samba samba_rwx_Amministrazione

Aggiunta di una condivisione

Ciascuna condivisione fa riferimento ad un path locale, nel caso descritto viene creata una cartella /share:

# mkdir /share

al di sotto della quale tutte le cartelle condivise verranno create:

1
2
3

# mkdir /share/Amministrazione
# chgrp samba_rwx_Amministrazione /share/Amministrazione
# chmod 2770 /share/Amministrazione

Queste operazioni andranno eseguite per ciascuna nuova condivisione creata e si riassumono come segue:

Creazione effettiva della cartella;
Assegnazione della cartella al gruppo creato;
Impostazione del permesso setgid (vedi sopra) ricorsivo sulla cartella appena creata;

Le condivisioni verranno definite nel file di configurazione smb.conf in coda alle dichiarazioni globali, in un formato simile al seguente:

[Amministrazione] 
comment = Amministrazione 
read only = no 
write list = @samba_rwx_Amministrazione
read list = 
path = /share/Amministrazione

Il codice illustrato definisce una condivisione denominata “Amministrazione” a cui possono accedere in scrittura nella directory “/share/Amministrazione” unicamente gli utenti appartenenti al gruppo “samba_rwx_Amministrazione”.

Pertanto, per aggiungere una condivisione sarà quindi sufficiente eseguire la creazione e l’assegnazione dei permessi come descritto sopra ed inserire all’interno del file /etc/samba/smb.conf una dichiarazione seguendo il modello indicato:

[] 
comment = 
read only = no 
write list = @
read list = @
path =

Nel caso l’accesso venga deciso unicamente in lettura o unicamente in scrittura, è possibile omettere le righe relative (write list o read list) dalla dichiarazione.

Attivazione delle configurazioni

Per applicare le nuove configurazioni, il servizio SAMBA necessita di essere ricaricato:

# service smbd reload

Da questo momento in poi sarà possibile utilizzare una qualsiasi macchina Microsoft Windows per testare l’effettivo successo delle configurazioni impostate.

Note

Quanto descritto consente di configurare SAMBA affinché possa interagire con client o server Microsoft Windows come se fosse un file e print server Microsoft.
E’ possibile variare le configurazioni in modo che SAMBA agisca da Primary Domain Controller (PDC), Backup Domain Controller o prendere parte ad un dominio Active Directory.
Sul portale tecnico sono disponibili diversi articoli che approfondiscono questi argomenti:

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (1 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (2 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (3 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (4 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (5 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (6 di 6)

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

In attesa quindi di saggiare le meraviglie dell’annunciato SAMBA 4, che conterrà un motore interno volto ad eguagliare l’efficienza e la funzionalità di Microsoft Active Directory, è chiaro come sia già possibile adottare SAMBA in ambiti produttivi di svariato genere, con successo, e senza costi di licenza.

Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

Raoul Scarazzini — Fri, 15 May 2009 15:40:00 +0000

Nel precedente articolo sono stati illustrati i metodi per effettuare delle interrogazioni ad un dominio Active Directory attraverso una macchina Linux al cui interno è configurato SAMBA. Nell’ultimo esempio illustrato l’esito dell’interrogazione presentava un elenco del tutto simile al contenuto del file /etc/passwd che in ogni sistema Linux contiene le informazioni di accesso degli utenti. La riflessione nata spontaneamente è quindi se si può fare in modo che il sistema sia configurato per supportare l’autenticazione via Active Directory in fase di login. La riposta è sì, ecco spiegato come.

Condividere una cartella

La configurazione illustrata nel primo articolo della serie consente di autenticare l’accesso a cartelle condivise mediante le credenziali presenti nel Active Directory.
Per condividere una cartella è sufficiente aggiungere al file di configurazione di SAMBA /etc/samba/smb.conf una dichiarazione come la seguente:

[Test]
        comment = Test
        path = /samba/test
        write list = DOMINIO.IT/user1
        read list = @"DOMINIO.ITgruop1"
        read only = Yes
        browseable = Yes
        create mask = 0775
        directory mask = 0775

dopo aver effettuato il reload del servizio attraverso il comando:

$ /etc/init.d/samba reload

la directory, supponendo che l’indirizzo IP della macchina sia 192.168.0.100, sarà disponibile per l’accesso dalla rete all’indirizzo //192.168.0.100/Test. L’utente DOMINIO.ITuser1 (così andrà digitato alla schermata di login) avrà il permesso di scrittura mentre tutti gli utenti del gruppo DOMINIO.ITgroup1 potranno accedere in lettura alla condivisione.

Ma questa è solo la punta dell’iceberg. Come già detto, la configurazione di SAMBA permette di sfruttare il metodo di autenticazione in modo che il sistema stesso in fase di login si riferisca al dominio Active Directory.

PAM, brevemente

PAM (Pluggable Authentication Modules) definisce un metodo standard ad alto livello per gestire l’autenticazione. Questo strato è comune a tutti i sistemi Linux (sebbene le varie versioni non operino tutte allo stesso modo) e consente a coloro i quali sviluppano servizi con autenticazioni proprie di creare moduli che rispettino l’interfaccia di programmazione relativa a PAM.
In questo modo, potenzialmente, qualunque sistema di autenticazione può essere integrato con il login di sistema.
Una panoramica dettagliata di quello che è PAM e di come funziona è disponibile presso Kernel.org, precisamente a questo link: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html.

Integrazione di winbind con PAM per il login via Active Directory

La configurazione di PAM all’interno del sistema è contenuta in una serie di file, in Debian Lenny, la distribuzione utilizzata in questa serie di articoli, tali file si trovano nella cartella /etc/pam.d:

$ ls -1 /etc/pam.d/
chfn
chsh
common-account
common-auth
common-password
common-session
cron
login
omauth
other
passwd
samba
ssh
su

In particolare i file interessati nella fase di login sono common-account, common-auth e common-session.

La componente SAMBA che gestisce l’interfacciamento con Active Directory è, come già spiegato, winbind. Il pacchetto fornito con le maggiori distribuzioni fornisce, fra gli altri, quello che è il file base per l’introduzione di Active Directory nel login di sistema: pam_winbind.so. Tale file dovrà essere introdotto all’interno della configurazione del sistema di login.

Il primo file ad essere modificato dovrà essere /etc/pam.d/common-account il cui contenuto dovrà essere il seguente:

account sufficient      pam_winbind.so
account required        pam_unix.so

Questo file di default controlla che la password dell’utente non sia scaduta. Con l’aggiunta della riga relativa a winbind inoltre assume come sufficiente la credenziale verificata da Active Directory.

Il secondo file da considerare sarà /etc/pam.d/common-auth che di default impone l’utilizzo del meccanismo UNIX standard per l’autenticazione. Tale file dovrà assumere questo contenuto:

auth    sufficient      pam_winbind.so
auth    required        pam_unix.so nullok_secure use_first_pass

Quanto inserito comunica al sistema di considerare sufficiente l’avvenuta autenticazione con winbind. Nella seconda riga viene aggiunto il parametro use_first_pass in modo che venga utilizzata la prima password inserita per autenticare l’utente e prevenire una doppia richiesta di inserimento per la parola d’ordine.

L’ultimo file che andrà modificato è /etc/pam.d/common-session che contiene le informazioni relative alle sessioni interattive e non che l’utente potrà avviare:

session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel umask=0022

rispetto al default viene aggiunta la riga relativa al modulo pam_mkhomedir.so per fare in modo che il sistema per ogni utente identificato che non possiede una home directory ne crei una ex-novo partendo dalle specifiche presenti nel file di /etc/skel con i permessi di scrittura relativi.

Prova di login

A questo punto il sistema è pronto a permettere il login alle utenze Active Directory, relativamente a tutti i servizi, compreso ssh:

$ ssh "DOMINIO.IT\user1"@192.168.0.100
DOMINIO.ITuser1@192.168.0.100's password: 
Creating directory '/home/DOMINIO.IT/user1'.
Linux anomalia 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686
 
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
 
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
DOMINIO.IT\user1@anomalia:~$

Essendo il primo tentativo di login effettuato e data la configurazione PAM precedentemente illustrata, il sistema ha creato la directory /home/DOMINIO.IT/user1.
Nella cartella /home/DOMINIO.IT verranno pertanto registrate tutte le home directories relative agli utenti:

$ ls -la /home/DOMINIO.IT/
totale 12
drwxr-xr-x 3 root                    root                             4096  9 apr 17:32 .
drwxr-xr-x 3 root                    root                             4096  9 apr 17:32 ..
drwxr-xr-x 2 DOMINIO.IT\user1 DOMINIO.IT\domain users 4096  9 apr 17:32 user1

L’accesso al sistema degli utenti Active Directory è garantito nella stessa medesima forma degli utenti di sistema standard.

Conclusioni

Questa panoramica di SAMBA ha voluto illustrare quello che è lo stato dell’arte dell’integrazione tra SAMBA e Microsoft Active Directory ad oggi, ma moltissime sono le novità che bollono in pentola dal team di sviluppo del progetto Samba. La versione 4 è ormai una realtà e sebbene la strada verso la prima release stabile sia lunga, le aspettative in merito sono altissime. Questa versione sarà la prima ad integrare la completa gestione di Active Directory ed un’altra serie di importanti novità che potranno, perché no, essere argomento di un prossimo articolo.

Articoli della serie

Samba e Active Directory (2 di 3): interrogare il dominio

Raoul Scarazzini — Wed, 06 May 2009 09:50:26 +0000

Dopo aver introdotto Active Directory ed aver configurato SAMBA per l’integrazione con un dominio vengono affrontati in questa seconda puntata i metodi per l’interrogazione dei domini: come ricavare le informazioni sugli utenti ed i gruppi, come accedere ad un computer di dominio ed eseguirvi un comando.
Il tutto attraverso gli strumenti offerti da SAMBA, dalla linea di comando.

Interrogazioni

Tra gli strumenti che samba mette a disposizione dalla linea di comando per l’interrogazione delle varie componenti del dominio ne verranno analizzati tre: net, già utilizzato nel precedente articolo per aggiungere la macchina al dominio, smbclient, un’interfaccia simile a quella di FTP ma utilizzabile per accedere a condivisioni Microsoft Windows e wbinfo, programma che interroga il demone winbind, la componente si SAMBA che si interfaccia con il servizio Active Directory.

net

l’opzione user del comando net associata alla specifica di -l consente di ricavare l’elenco utenti del dominio specificato nel file di configurazione di SAMBA:

$ net -U Administrator ads user -l
Enter Administrator's password:
 
User name             Comment
-----------------------------
user1                 Utente di test #1
Guest                 Built-in account for guest access to the computer/domain
...
...

Allo stesso modo specificando l’opzione group è possibile ottenere l’elenco gruppi:

$ net -U Administrator ads group -l
Enter Administrator's password:
 
Group name            Comment
-----------------------------
Exchange Servers      This group contains all the Exchange servers. This group should not be deleted.
Exchange Organization Users in this group will have permission to read and modify all Exchange configuration. This group should not be deleted.
Exchange Recipient Ad Users in this group can manage Exchange user attributes in the Active Directory and perform select mailbox operations. This group should not be deleted.
...
...

net permette anche di creare, cancellare e rinominare utenti e gruppi, ad esempio per creare il gruppo test_group il comando sarà:

$ net -U Administrator ads group ADD test_group
Administrator's password: 
Group test_group added

Parallelamente un utente potrà esser creato come segue:

$ net -U Administrator ads user ADD test_user
Administrator's password: 
User test_user added

Purtroppo net non consente ancora di operare sull’appartenenza dei gruppi, che è prevista nelle versioni future di SAMBA. Tutti le opzioni disponibili possono essere visionate nella man page del comando accessibile digitando man net.

smbclient con il ticket KERBEROS

Il tool smbclient offre un’interfaccia testuale con comandi simili a quelli ftp attraverso i quali è possibile interrogare ed agire su cartelle relative a condivisioni di tipo SMB/CIFS (cioè Microsoft Windows). Se già da questo punto di vista lo strumento appare subito utilissimo esiste un ulteriore vantaggio che lo rende indispensabile per le architetture Linux integrate con Active Directory: infatti smbclient può utilizzare l’autenticazione KERBEROS descritta nel precedente articolo per connettersi ai servizi remoti.
Prima di presentare gli esempi di utilizzo è quindi necessario fare acquisire al sistema il ticket KERBEROS attraverso il comando kinit:

$ kinit -V Administrator@DOMINIO.IT
Password for Administrator@DOMINIO.IT:
Authenticated to Kerberos v5

Il sistema è quindi in possesso della verifica necessaria per presentarsi ai servizi remoti. Utilizzando l’opzione -k di smbclient è possibile ad esempio sfogliare un computer di dominio del quale si conosce l’indirizzo IP o il nome. Nel nostro caso il sistema si chiama Test-win03 e l’invocazione di smbclient con i parametri utilizzati elencherà tutte le condivisioni disponibili sul server pubblico Microsoft:

$ smbclient -k -L Test-win03
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
 
       Sharename           Type      Comment
       ---------           ----       -------
       print$              Disk       Driver della stampante
       C$                  Disk       Condivisione predefinita
       IPC$                IPC        IPC remoto
       ADMIN$              Disk      Amministrazione remota
       HPLaserJ            Printer   HP LaserJet 4100 Series PS
       musica              Disk      
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
 
	Server               Comment
	---------            -------
 
	Workgroup            Master
	---------            -------

L’output del comando mostra quali condivisioni sono disponibili sul server remoto, su queste è quindi possibile eseguire dei comandi. Ad esempio per effettuare il listato del contenuto della cartella musica è possibile invocare smbclient in questa forma:

$ smbclient -k //Test-win03/musica -c "ls"
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
  .                                   D        0  Mon Feb 16 17:13:06 2009
  ..                                  D        0  Mon Feb 16 17:13:06 2009
  Cartoni Animati                     D        0  Mon May 19 13:39:51 2008
  Collaborazioni                      D        0  Mon Feb 16 11:17:12 2009
  Cover                               D        0  Thu Dec 18 16:04:02 2008
...
...

smbclient dispone inoltre di una shell, in tutto e per tutto simile ad una shell di tipo ftp. Per accedervi è sufficiente invocare smbclient senza altri paramente che il già citato -k ed il nome della macchina seguito dalla cartella:

$ smbclient //Test-win03/musica -k
OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: >

I comandi disponibili nell’interfaccia si ottengono digitando help:

smb: >help
?              altname        archive        blocksize      cancel         
case_sensitive cd             chmod          chown          del            
dir            du             exit           get            getfacl        
hardlink       help           history        lcd            link           
lowercase      ls             mask           md             mget           
mkdir          more           mput           newer          open           
print          prompt         put            pwd            q              
queue          quit           rd             recurse        reget          
rename         reput          rm             rmdir          showacls       
setmode        stat           symlink        tar            tarmode        
translate      volume         vuid           logon          listconnect    
showconnect    !

Altre informazioni utili su smbclient sono ottenibili attraverso la man page (man smbclient) del programma.

wbinfo

L’ultimo comando illustrato è wbinfo che come anticipato permette di interrogare il demone winbind responsabile delle comunicazione tra SAMBA ed Active Directory e l’integrazione dei due sistemi. In particolare il demone si occupa di effettuare il mapping delle utenze, di associare cioè l’identificativo univoco presente sul dominio ad un identificativo univoco LOCALE alla macchina SAMBA.
Per capire quanto illustrato, si osservi il seguente comando:

$ for i in `wbinfo -u --domain=DOMINIO.IT`; do wbinfo -i "$i"; done
DOMINIO.ITuser1:*:10000:10004:User 1:/home/DOMINIO.IT/user1:/bin/bash
DOMINIO.ITuser2:*:10001:10004:User 2:/home/DOMINIO.IT/user2:/bin/bash
DOMINIO.ITuser3:*:10002:10004:User 3:/home/DOMINIO.IT/user3:/bin/bash
DOMINIO.ITuser4:*:10003:10004:User 4:/home/DOMINIO.IT/user4:/bin/bash
...
...

L’elenco ricavato dal comando è del tutto simile a quanto contenuto nel file /etc/passwd di sistema, ad ogni utenza è infatti associato un identificativo univoco, un gruppo, una home dir ed una shell di login.
Anche in questo caso tutte le opzioni disponibili per il comando wbinfo sono disponibili nella man page (man wbinfo).

Conclusioni

L’esito dell’ultimo comando illustrato introduce quello che sarà l’argomento della prossima ed ultima puntata di questa serie: l’integrazione di Active Directory con il login di sistema attraverso la configurazione di PAM.

Articoli della serie

Samba e Active Directory (1 di 3): diventare parte di un Dominio

Raoul Scarazzini — Thu, 23 Apr 2009 15:00:15 +0000

In questa serie di tre articoli verrà affrontata l’integrazione tra Samba ed Active Directory: Come aggiungere un sistema Linux ad un dominio Active Directory configurando opportunamente Samba, come effettuare interrogazioni relative ai dati del dominio attraverso i tool messi a disposizione dal pacchetto ed infine come configurare le librerie PAM del sistema affinché le autenticazioni per l’accesso vengano effettuate attraverso il dominio.
Nella prima parte oltre ad un’introduzione su Active Directory verrà trattata la configurazione di SAMBA per l’integrazione con un dominio.

Cos’è Active Directory

Active Directory di Microsoft Windows è ormai l’insieme di servizi standard per i sistemi che accentrano i dati relativi alle risorse di un dominio, siano queste utenti, computer o periferiche, tutti fanno capo al direttorio centralizzato che è disponibile nel sistema operativo Microsoft Windows dalla versione 2000 in poi.
Molti sono i servizi che entrano in gioco in un dominio Active Directory ad esempio le informazioni relative alle risorse sono registrate in un direttorio LDAP opportunamente personalizzato da Microsoft, la risoluzione dei nomi è affidata al servizio DNS interno ai server Active Directory.
La componente base di Active Directory è il protocollo Kerberos, che permette di autenticarsi in maniera cifrata.
Una volta che la propria identità viene riconosciuta, è quindi possibile accedere in maniera sicura a tutte le risorse per le quali si possiedono i permessi. Tale peculiarità è definita SSO o Single Sign-On.

Configurazione del sistema

Il sistema che viene configurato nell’esempio parte da questi presupposti: il dominio Active Directory è DOMINIO.IT ed è erogato da tre server adserver1.dominio.it, adserver2.dominio.it ed adserver3.dominio.it. Si parte dal presupposto che si disponga di un’utenza amministrativa (Administrator) o comunque di un’utenza che abbia i permessi di aggiungere computer al dominio. Il server SAMBA configurato sarà appunto un computer aggiunto al dominio DOMINIO.IT.

Installazione KERBEROS

Per far funzionare Kerberos su un sistema Linux (in questo caso, come detto, Debian Lenny) è sufficiente il pacchetto krb5-user. Tale pacchetto contiene tutti gli eseguibili necessari all’interfacciamento con i server di autenticazione. Inoltre, per completezza, è conveniente installare anche il pacchetto krb5-config contenente un template relativo ai file di configurazione e krb5-doc che contiene la documentazione completa del funzionamento di Kerberos sotto Linux:

$ apt-get install krb5-user krb5-config krb5-doc

Il file di configurazione /etc/krb5.conf contiene le impostazioni necessarie al collegamento con il (o “i”) server di autenticazione e, pertanto, dovrà contenere le informazioni ad essi associate:

[libdefaults]
        default_realm = DOMINIO.IT
 
[realms]
        DOMINIO.IT = {
                kdc = adserver1.dominio.it
                kdc = adserver2.dominio.it
                kdc = adserver3.dominio.it
                admin_server = adserver1.dominio.it
                  }

Nella sezione libdefaults sono definite le informazioni di default per la libreria krb5, la sezione realms contiene le definizioni specifiche relative ai vari domini dichiarati, nel caso sopra descritto vi sono definiti i tre server kdc (acronimo che sta per Key Distribution Server) ai quali vengono richiesti i permessi di accesso alle risorse ed il parametro admin_server che indica il Master Kerberos server ossia il principale erogatore del servizio.
La configurazione illustrata è minimale e permette i test che verranno effettuati, ma molte altre sono le opzioni relative a Kerberos e sono disponibili nella man page consultabile attraverso questo comando:

$ man krb5.conf

A completamento della configurazione sono necessarie due ulteriori operazioni, la prima è l’aggiunta dei server dichiarati nel file krb5.conf nel file hosts:

# ADs Servers
192.168.0.1    adserver1.dominio.it
192.168.0.2    adserver2.dominio.it
192.168.0.3    adserver3.dominio.it

In questo modo malfunzionamenti nel sistema di risoluzione dei nomi (e cioè del server DNS dichiarato in /etc/resolv.conf) non comporteranno l’interruzione del servizio.
La seconda operazione riguarda l’orario del sistema che deve essere assolutamente esatto per potersi interfacciare con un server Active Directory, installando quindi il pacchetto ntpdate è possibile sistemare l’orario automaticamente, puntando un servizio ntp pubblico come time.ien.it:

$ apt-get install ntpdate
$ ntpdate time.ien.it
 9 Apr 16:44:53 ntpdate[2806]: step time server 193.204.114.105 offset -7226.860681 sec

Sebbene l’argomento non sia trattato in questo articolo, ideale sarebbe avere un sistema automatizzato che costantemente sistemi l’orario, come ad esempio openntpd.
A questo punto, terminata la configurazione, è tempo di richiedere il primo ticket al server attraverso il comando kinit. La richiesta dovrà essere fatta da un utente privilegiato (quindi Administrator o chi per esso):

$ kinit -V Administrator@DOMINIO.IT
Password for Administrator@DOMINIO.IT:
Authenticated to Kerberos v5

Se il messaggio restituito dal comando è “Authenticated to Kerberos v5″, allora tutto è andato come da pronostico. In alternativa sarà necessario controllare la bontà dei dati inseriti e rilanciare il comando.

Installazione SAMBA e Winbind

Il secondo componente da configurare per l’attuazione del progetto è SAMBA insieme alla parte che si occupa di interfacciarsi con i server Microsoft Windows per il reperimento delle informazioni di dominio:

$ apt-get install samba smbclient smbfs winbind

Il contenuto del file di configurazione di SAMBA, /etc/samba/smb.conf, dovrà essere simile al seguente:

[global]
        realm = DOMINIO.IT
        server string = %h : Samba %v
        security = ADS
        auth methods = guest, sam, winbind
        password server = adserver1.dominio.it, adserver2.dominio.it, adserver3.dominio.it
        log level = 3 passdb:10 auth:10 winbind:10
        max log size = 50
        load printers = No
        show add printer wizard = No
        preferred master = No
        ldap ssl = no
        idmap uid = 10000-200000
        idmap gid = 10000-200000
        template shell = /bin/bash
        create mask = 0770
        directory mask = 0770
        reset on zero vc = yes

La configurazione al di là delle opzioni ininfluenti per il progetto, prevede i seguenti parametri:

realm: il dominio active directory DOMINIO.IT;
security: il tipo di funzionamento che SAMBA deve assumere, che è “ADS” (Active Directory);
auth methods: i metodi di autenticazione che sono guest (ospite), sam (il database standard delle utenze SAMBA) e winbind (attraverso Microsoft Windows);
password server: i server presso i quali autenticarsi (identici a quelli dichiarati per Kerberos);
idmap uid e idmap gid: gli identificativi di partenza con cui mappare le utenze lette dai server Windows, in modo che a queste utenze possano essere assegnati permessi locali;
reset on zero vc: indica al sistema di resettare una connessione se ne subentra un’altra dallo stesso indirizzo IP. Quest’opzione è utile quando le connessioni di rete non sono stabili e Microsoft Windows riapre una nuova connessione sebbene la precedente abbia ancora dei file allocati;

Prima di avviare il servizio SAMBA è necessaria una variazione al file /etc/nsswitch.conf in modo da indicare al sistema che i dati per le autenticazioni possono essere ricercati oltre che nei file locali, anche nel server winbind, pertanto le righe corrispondenti a queste informazioni andranno variate come indicato di seguito:

passwd:         compat winbind
group:          compat winbind
...
hosts:          files dns wins

A questo punto dopo il riavvio dei servizi appena configurati:

$ /etc/init.d/samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
$ /etc/init.d/winbind restart
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.

Si potrà includere il server all’interno del dominio utilizzando il comando net per eseguire l’operazione di join:

$ net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- DOMINIO
Joined 'ANOMALIA' to realm 'dominio.it'

L’output del comando conferma che il server ora è parte del dominio. Un’ulteriore verifica è effettuabile sempre attraverso il comando net mediante l’utilizzo dell’opzione info:

$ net ads info
LDAP server: 192.168.0.1
LDAP server name: adserver1.dominio.it
Realm: DOMINIO.IT
Bind Path: dc=DOMINIO,dc=IT
LDAP port: 389
Server time: gio, 09 apr 2009 17:07:33 CEST
KDC server: 192.168.0.1
Server time offset: 2

Conclusioni

Nella prossima puntata verranno illustrate le tecniche per interrogare le risorse ed accedervi.

Articoli della serie

RAID Software : Proteggere i dati con l’aiuto del kernel (5 di 5)

Raoul Scarazzini — Tue, 07 Apr 2009 07:20:31 +0000

Dopo il primo case study relativo all’impiego di mdadm per la creazione di un sistema RAID 1 con disco estraibile, l’ultima puntata di questa serie di articoli presenta nel dettaglio una soluzione di network Raid 1 creata attraverso il software drbd, per una replica in rete del disco contenente i dati e la condivisione di questi attraverso i servizi NFS e SAMBA, in alta affidabilità.

DRBD : Network RAID 1

Fino ad ora sono state illustrate soluzioni RAID applicate a singole macchine, ma è possibile garantire la protezione dai dati anche attraverso RAID distribuiti, in soluzioni ad alta affidabilità. Uno fra i progetti più interessanti in questo ambito, giunto allo stato di piena maturità, è sicuramente DRBD (http://www.drbd.org).
DRBD permette di replicare dati (in mirror, sul modello del RAID 1) da una macchina primaria definita “master” ad una secondaria definita “slave” attraverso una connessione di rete dedicata, tipicamente ottenuta dal collegamento di due schede di rete attraverso un cavo “cross” (senza disporre quindi di uno switch apposito).
Tecnicamente DRBD è un modulo del kernel, proprio come sono moduli quelli del RAID e come per questi moduli la gestione di DRBD è affidata ad una serie di utilities che comprende (come per mdadm) un demone che gestisce ed attiva le configurazioni. La sostanziale differenza tra DRBD ed i moduli standard di RAID è che questo modulo non è ancora incluso nei sorgenti ufficiali del kernel. Per questo motivo prima di poter utilizzare DRBD è necessario compilare il moduli del kernel partendo dai sorgenti.
Tipicamente DRBD viene utilizzato insieme al programma heartbeat, che consente di estenderne le funzionalità attraverso la gestione dei failover. Per failover si intendono tutte quelle situazioni in cui un servizio erogato da una macchina, se questa smette di funzionare, rimane accessibile attraverso una seconda che ne garantisce l’accessibilità costante.
I servizi erogabili attraverso heartbeat sono molteplici e possono riguardare i più svariati utilizzi : da un webserver ad un database MySQL, per arrivare a dei filesystem condivisi via NFS o SAMBA.
Nel case study di questo paragrafo verranno illustrate le operazioni necessarie all’installazione di DRBD e alla sua integrazione con heartbeat affinché condivida un filesystem in rete via NFS e SAMBA.

Case Study 2 – DRBD in una soluzione di alta affidabilità con heartbeat, NFS e SAMBA.

Il seguente case study descrive quanto è stato fatto per la società 3Dvision che effettua consulenza, supervisione e produzione di elaborazioni digitali destinate ai settori pubblicitario, promozionale e televisivo.
La grande quantità di dati trattati e la criticità del loro contenuto hanno sempre imposto la memorizzazione di questi attraverso hardware proprietario. Nella rete era infatti installato un dispositivo NAS (Network Attached Storage), che attraverso un sistema operativo proprietario, rendeva disponibile il proprio spazio.
Nel momento in cui il NAS si è guastato, si è optato per una scelta di radicale cambiamento, basata su hardware di consumo e software Opensource. E’ stato quindi acquistato hardware per creare due macchine identiche ciascuna con processore AMD Sempron 3200 MegaHertz, un GigaByte di RAM, due schede di rete Gigabit e quattro dischi da 300 GigaByte.
L’obiettivo finale è stato quello di ottenere 1,2 Tb di spazio debitamente protetto e condiviso in rete attraverso SAMBA ed NFS.

Sviluppo del progetto

Su entrambe le macchine è stato installato il sistema operativo Debian Sarge in forma minimale, senza cioè ambiente grafico, attraverso un lettore DVD esterno collegato via USB. In questo modo si sono potuti sfruttare tutti e due i canali IDE per il collegamento dei quattro dischi da 300 GigaByte gestiti attraverso il kernel in RAID 0, per un totale di 1,2 TeraByte di spazio disponibile.
Per ovviare all’insicurezza dettata dalla scelta del RAID 0 (se un disco dei quattro cessa di funzionare, tutto il sistema cade) si è scelto di effettuare un RAID 1 in rete attraverso DRBD. In questo modo si è sfruttata la capacità di scrittura parallela del RAID 0 e l’affidabilità della copia dati del Network RAID 1 via DRBD.
Il progetto è rappresentato in figura 5 :

Figura 5

Configurazione di DRBD

Al termine delle installazioni lo schema di partizionamento delle macchine è il seguente :

$ fdisk -l
 
Disk /dev/hda: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          30      240943+  82  Linux swap / Solaris
/dev/hda2              31        1246     9767520   83  Linux
/dev/hda3            1247       36483   283041202+  fd  Linux raid autodetect
 
Disk /dev/hdb: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1          30      240943+  82  Linux swap / Solaris
/dev/hdb2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/hdc: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1               1          30      240943+  82  Linux swap / Solaris
/dev/hdc2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/hdd: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1          30      240943+  82  Linux swap / Solaris
/dev/hdd2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/md0: 1189.3 GB, 1189342216192 bytes
2 heads, 4 sectors/track, 290366752 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
 
Disk /dev/md0 doesn't contain a valid partition table

Ciascuno dei quattro dischi contiene un’area di swap ed un’area dedicata al RAID, solo il primo dei quattro contiene una partizione da 10 Giga destinata alla partizione root.
Lo stato del RAID 0 sulle due macchine è il seguente :

$ cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [faulty]
md0 : active raid0 hdd2[3] hdc2[2] hdb2[1] hda3[0]
      1161467008 blocks 64k chunks
 
unused devices:

Entrambe possiedono una device /dev/md0 di circa 1,2 TeraByte gestita in RAID 0 dal kernel.
La prima fase del progetto riguarda l’installazione dei pacchetti necessari a ricompilare il kernel secondo la comodissima metodologia Debian, insieme alle utility ed ai sorgenti di DRBD :

$ apt-get install kernel-source kernel-package bzip2 libncurses5-dev drbd0.7-utils drbd0.7-module-source

Per creare il kernel personalizzato vanno decompressi i sorgenti e lanciata la configurazione che va effettuata sulla base dell’hardware delle macchine impiegate :

$ cd /usr/src/
$ tar -xjvf kernel-source-2.6.8.tar.bz2
$ cd /usr/src/kernel-source-2.6.8
$ make menuconfig

Terminata questa fase, andranno creati i pacchetti relativi al kernel ed ai moduli DRBD :

$ make-kpkg --revision 1 --append-to-version rasca-3dv kernel_image
$ make-kpkg --revision 1 --append-to-version rasca-3dv modules_image
$ ls -1 /usr/src/
drbd0.7-module-2.6.8rasca-3dv_0.7.10-4+1_i386.deb
drbd0.7.tar.gz
kernel-image-2.6.8rasca-3dv_1_i386.deb
linux-source-2.6.8
linux-source-2.6.8.tar.bz2
modules

E di conseguenza installati :

$ dpkg -i kernel-image-2.6.8rasca-3dv_1_i386.deb drbd0.7-module-2.6.8rasca-3dv_0.7.10-4+1_i386.deb

Il sistema va avviato col nuovo kernel (vanno ignorati gli errori in fase di boot del demone DRBD in quanto non è stato ancora configurato). Per verificare che il sistema sia stato avviato col nuovo kernel è sufficiente lanciare il comando “uname -a” :

$ uname -a
Linux 3dv-ha-1 2.6.8rasca-3dv #1 PREEMPT Sat Jun 17 20:56:39 CEST 2006 i686 GNU/Linux

Il sistema è quindi pronto per la configurazione di DRBD. Come da specifiche, le interfacce presenti nel sistema sono 3, eth0 (Gigabit, PCI) collegata alla LAN, eth1 (Gigabit, PCI) collegata attraverso il cavo cross all’altra macchina e eth2 (Megabit, integrata nella scheda madre) scollegata :

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:14:C1:0F:50:AF
          inet addr:192.168.0.8  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19841 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32402 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6882512 (6.5 MiB)  TX bytes:42354250 (40.3 MiB)
          Interrupt:177 Base address:0xe000
 
eth1      Link encap:Ethernet  HWaddr 00:14:C1:0F:50:AA
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:218 (218.0 b)  TX bytes:218 (218.0 b)
          Interrupt:185
 
eth2      Link encap:Ethernet  HWaddr 00:15:F2:D0:FC:B9
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:193 Base address:0xa400

Il file di configurazione di DRBD è /etc/drbd.conf ed è diviso a blocchi. Per ogni risorsa esiste un blocco nominato “resource” contenente dei sotto-blocchi. Ciascuno dei blocchi si apre e si chiude con una parentesi graffa. Per le esigenze del progetto, la compilazione ideale è la seguente :

resource drbd0 {
  protocol C;
  incon-degr-cmd "echo '!DRBD! primario sui dati inconsistenti' | wall ; sleep 60 ; halt -f";
 
  startup {
    degr-wfc-timeout 120;
  }
 
  disk {
    on-io-error   detach;
  }
 
  net {
    timeout       80;
    connect-int   10;
    ping-int      10;
    ko-count      4;
    max-buffers   4096;
    max-epoch-size  2048;
  }
 
  syncer {
    rate 650M;
    group 0;
    al-extents 521;
  }
 
  on 3dv-ha-1 {
    device     /dev/drbd0;
    disk       /dev/md0;
    address    10.0.0.1:7788;
    meta-disk  internal;
  }
 
  on 3dv-ha-2 {
    device    /dev/drbd0;
    disk      /dev/md0;
    address   10.0.0.2:7788;
    meta-disk internal;
  }
}

Le opzioni del file sono auto esplicative ed attraverso la man page di drbd.conf è possibile conoscerne tutti i particolare (digitando “man drbd.conf”).
All’interno del blocco “resource” viene indicato il nome che la device DRBD avrà per il sistema ed il messaggio che il kernel riceverà in caso di malfunzionamento.
Il blocco “startup” contiene il tempo di attesa che in fase di boot il demone DRBD attenderà per ricevere notifica di esistenza da parte della macchina associata.
“disk” è il blocco contenente il tipo di comportamento che il demone dovrà assumere in caso di errori relativi alla device, nel caso descritto sarà “detach” ossia “Stacca”, “Sconnetti”.
Nel blocco “net” sono presenti le dichiarazioni relative al collegamento di rete tra le due macchine ossia il tempo che deve trascorrere tra un ping e l’altro (necessario per capire se l’altra macchina è in linea), la grandezza del buffer e così via.
Nel blocco “syncer” è contenuta una tra le opzioni più importanti per le performances, e cioè “rate”. Tale parametro infatti regola il numero massimo di byte per secondo che il demone utilizzerà per replicare i dati tra il computer master e lo slave. Nel caso illustrato tale parametro, in forza alle interfacce Gigabit con cui le due macchine sono collegate fra loro, è stato settato al massimo disponibile, ossia 650 MegaByte.
Gli ultimi due blocchi descrivono le due macchine impiegate nel RAID 1 e per ciascuna la device DRBD utilizzata, il filesystem locale condiviso, l’IP della macchina, la porta di ascolto del demone DRBD ed il tipo di meta-disk (interno).
Terminata la compilazione del file, che dovrà essere IDENTICO per ciascuna delle due macchine, si potrà procedere al riavvio del servizio DRBD su entrambi i nodi :

$ /etc/init.d/drbd restart

All’interno del file /var/log/syslog verranno riportate le fasi di attivazione del Network RAID 1 :

Jun 18 21:14:55 3dv-ha-1 kernel: drbd: module cleanup done.
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: initialised. Version: 0.7.10 (api:77/proto:74)
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: registered as block device major 147
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: Creating state block
Jun 18 21:14:55 3dv-ha-1 kernel: klogd 1.4.1, ---------- state change ----------
Jun 18 21:14:55 3dv-ha-1 kernel: No module symbols loaded - kernel modules not enabled.
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: resync bitmap: bits=290333984 words=9072938
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: size = 1107 GB (1161335936 KB)
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: Assuming that all blocks are out of sync (aka FullSync)
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: 1161335936 KB now marked out-of-sync by on disk bit-map.
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbdsetup [3151]: cstate Unconfigured --> StandAlone
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbdsetup [3154]: cstate StandAlone --> Unconnected
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate Unconnected --> WFConnection
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate WFConnection --> WFReportParams
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Connection established.
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: I am(S): 0:00000001:00000001:00000001:00000001:00
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Peer(S): 0:00000001:00000001:00000001:00000001:00
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate WFReportParams --> Connected
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: I am inconsistent, but there is no sync? BOTH nodes inconsistent!
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Secondary/Unknown --> Secondary/Secondary

I due host avviati da DRBD sono connessi ma il Network RAID 1 non è ancora attivo. Lo si evince dal messaggio “I am inconsistent, but there is no sync?”. Questo perché i due dischi non sono mai stati sincronizzati. Abbiamo comunque la conferma che il primo nodo è primario, quindi ciò che rimane da fare è forzare la prima sincronizzazione attraverso il seguente comando sul nodo master :

$ drbdadm -- --do-what-I-say primary all

Su entrambi i nodi si può osservare lo stato della ricostruzione, visualizzando lo stato del Network RAID 1 contenuto nel file “drbd” della directory /proc, nella stessa maniera in cui veniva visualizzata la ricostruzione per i RAID creati con mdadm :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:54361636 nr:0 dw:0 dr:54378020 al:0 bm:3317 lo:27 pe:55 ua:4096 ap:0
        [>...................] sync'ed:  4.9% (1036021/1089109)M
        finish: 5:18:23 speed: 55,492 (54,036) K/sec

Lavorando con quantità di dati così ampie, la prima ricostruzione impiegherà poco più di quattro ore per completarsi :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:738278800 nr:0 dw:0 dr:738295184 al:0 bm:45060 lo:0 pe:6 ua:4096 ap:0
        [=============>......] sync'ed: 66.2% (368133/1089109)M
        finish: 1:53:34 speed: 55,288 (53,956) K/sec

Al termine di tale ricostruzione, lo stato del Network RAID 1 è il seguente :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:1115247744 nr:0 dw:0 dr:1115247744 al:0 bm:68070 lo:0 pe:0 ua:0 ap:0

Dal nodo master è quindi possibile creare un filesystem ext3 sulla neo-creata device :

$ mke2fs -j /dev/drbd0
mke2fs 1.37 (21-Mar-2005)
Etichetta del filesystem=
Tipo SO: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
145178624 inode, 290333984 blocchi
14516699 blocchi (5.00%) riservati per l'utente root
Primo blocco dati=0
8861 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
16384 inode per gruppo
Backup del superblocco salvati nei blocchi:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
 
Scrittura delle tavole degli inode: fatto
Creazione del journal (8192 blocchi): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto
 
Questo filesystem verrà automaticamente controllato ogni 30 mount, o
180 giorni, a seconda di quale venga prima. Usare tune2fs -c o -i per cambiare.

Ed infine montare il nuovo filesystem nella directory /store (sempre e solo sul nodo master) :

$ mount /dev/drbd0 /store

Attraverso il comando “df”, è possibile osservare lo stato del Network RAID 1 :

$ df -h
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/hda2             9,2G 1001M  7,8G  12% /
tmpfs                 443M     0  443M   0% /dev/shm
/dev/drbd0            1,1T   33M  1,1T   1% /store

Ma per ottenere quanto stabilito all’inizio del progetto è necessario spingersi oltre, configurando heartbeat in modo che controlli il filesystem DRBD e ne condivida il contenuto via NFS e SAMBA, in alta affidabilità.
Su ciascuna delle due macchine andranno quindi configurati i due servizi insieme al demone heartbeat.

Configurazione di NFS

La configurazione di NFS va effettuata su entrambe le macchine, in quanto in caso di malfunzionamento di una di queste, l’altra attraverso heartbeat sarà in grado di continuare ad erogare il servizio.
Per installare il pacchetto nfs-kernel-server è sufficiente lanciare il comando :

$ apt-get install nfs-kernel-server

l’installazione di NFS, implica l’avvio del servizio. Ma in funzione del fatto che tale servizio sarà controllato da heartbeat, il demone va fermato :

$ /etc/init.d/nfs-kernel-server stop
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon...done.

E rimosso dall’avvio automatico durante il boot del sistema :

$ update-rc.d -f nfs-kernel-server remove
update-rc.d: /etc/init.d/nfs-kernel-server exists during rc.d purge (continuing)
 Removing any system startup links for /etc/init.d/nfs-kernel-server ...
   /etc/rc0.d/K80nfs-kernel-server
   /etc/rc1.d/K80nfs-kernel-server
   /etc/rc2.d/S20nfs-kernel-server
   /etc/rc3.d/S20nfs-kernel-server
   /etc/rc4.d/S20nfs-kernel-server
   /etc/rc5.d/S20nfs-kernel-server
   /etc/rc6.d/K80nfs-kernel-server

Il servizio NFS tipicamente registra le informazioni di lock dei file nella directory /var/lib/nfs. Nel caso in esame però tale servizio, in caso di malfunzionamento, potrebbe cambiare da una macchina all’altra. E’ facile capire come nel caso in cui un file venisse bloccato sulla macchina master (quindi con le informazioni di blocco scritte nella directory /var/lib/nfs della macchina master), se il servizio NFS effettuasse uno switch, tali informazioni non sarebbero più disponibili.
Pertanto, è necessario configurare la cartella dei lock sul filesystem condiviso.
Sulla macchina master quindi andrà copiata la cartella /var/lib/nfs in /store :

$ mv /var/lib/nfs /store/

Mentre sul nodo slave, tale directory andrà rimossa :

$ rm -rf /var/lib/nfs

Il vecchio path andrà infine collegato al nuovo su entrambi i sistemi :

$ ln -s /store/nfs /var/lib/nfs

Sul nodo slave NON esiste la cartella /store/nfs, ma esisterà nel momento in cui il servizio NFS (e quindi il filesystem DRBD) effettuerà lo switch.
Infine, nel file /etc/default/nfs-common, il parametro STATDOPTS andrà modificato così :

STATDOPTS="-n 3dv-ha"

Questa opzione è necessaria in quanto il demone che controlla gli stati del servizio NFS (STATD) associa gli stati che controlla al nome dell’host. Anche in questo caso, nel momento in cui la macchina effettuerà lo switch del servizio, il nome host cambierà. Con questa opzione STATD non farà confusione e assocerà gli stati sempre al nome host “virtuale” 3dv-ha.

L’ultima operazione riguarda la configurazione delle directory condivise nel file /etc/exports su entrambi i nodi :

/store/Progetti 192.168.0.0/255.255.255.0(rw,async)

In questo modo è garantito il permesso a qualsiasi host della rete 192.168.0 di montare in lettura e scrittura la cartella /store/Progetti.

Configurazione di SAMBA

Dopo aver aggiornato i repositories di apt come spiegato nel case study precedente, si può procedere con l’installazione degli ultimi pacchetti SAMBA disponibili :

$ apt-get install samba smbfs smbclient

La più semplice delle configurazioni (personalizzabile a seconda delle esigenze) del file /etc/samba/smb.conf potrebbe essere la seguente :

[global]
   workgroup = 3DVISION
   server string = %h server (Samba %v)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam guest
   obey pam restrictions = yes
   invalid users = root
   passwd program = /usr/bin/passwd %u
   passwd chat = *EntersnewsUNIXspassword:* %nn *RetypesnewsUNIXspassword:* %nn .
   load printers = no
   socket options = TCP_NODELAY
 
[Progetti]
   comment = Progetti
   browsable = yes
   path = /store/Progetti
   guest ok = no
   writable = no
   share modes = no
   write list = @3dvision
   create mask = 0770
   directory mask = 0770

Viene quindi garantito l’accesso in scrittura alla cartella “Progetti” (che è stata creata con maschera 770 ed appartiene all’utente “3dv_user”) a tutti gli utenti appartenenti al gruppo “3dvision” :

$ mkdir /store/Progetti
$ chown 3dv_user:3dvision /store/Progetti
$ chmod 770 /store/Progetti
$ ll /store/
totale 28
drwx------  2 root     root     16384 2006-06-19 04:01 lost+found
drwxr-xr-x  4 root     root      4096 2006-06-20 17:47 nfs
drwxrwx---  2 3dv_user 3dvision  4096 2006-06-20 17:52 Progetti

Anche per il servizio SAMBA, è necessario rimuovere l’avvio automatico al boot del sistema :

$ update-rc.d -f samba remove
update-rc.d: /etc/init.d/samba exists during rc.d purge (continuing)
 Removing any system startup links for /etc/init.d/samba ...
   /etc/rc0.d/K19samba
   /etc/rc1.d/K19samba
   /etc/rc2.d/S20samba
   /etc/rc3.d/S20samba
   /etc/rc4.d/S20samba
   /etc/rc5.d/S20samba
   /etc/rc6.d/K19samba

In questo modo anche il servizio SAMBA è configurato.

Configurazione di Heartbeat

L’ultima fase relativa al nostro progetto riguarda l’installazione di heartbeat :

$ apt-get install heartbeat

Per il quale sarà necessario aggiungere l’utente “cluster”, necessario per le interrogazioni sullo stato del cluster :

$ adduser cluster
Adding user `cluster'...
Adding new group `cluster' (1002).
Adding new user `cluster' (1002) with group `cluster'.
Creating home directory `/home/cluster'.
Copying files from `/etc/skel'
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Modifica delle informazioni relative all'utente cluster
Inserire il nuovo valore o premere INVIO per quello predefinito
        Nome completo []:
        Stanza n° []:
        Numero telefonico di lavoro []:
        Numero telefonico di casa []:
        Altro []:
Is the information correct? [y/N] y

Il file di configurazione di heartbeat è /etc/ha.d/ha.cf e per il nodo master sarà il seguente :

logfacility daemon
keepalive 1
deadtime 14
warntime 7
initdead 120
udpport 694
baud 19200
serial /dev/ttyS0
ucast eth1 10.0.0.2
ucast eth0 192.168.0.9
auto_failback off
watchdog /dev/watchdog
node    3dv-ha-1
node    3dv-ha-2
ping 192.168.0.69
respawn cluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=cluster uid=cluster
deadping 30
logfile /var/log/ha.log

Senza studiare a fondo ciascuna delle opzioni, ciò che interessa di più sono i parametri “ucast” che dovranno variare dal nodo master al nodo slave, in quanto rappresentano gli indirizzi IP attraverso i quali avverrà lo scambio delle informazioni per l’alta affidabilità (l’heartbeat appunto o “battito cardiaco”). Tali opzioni infatti sul nodo slave saranno esattamente l’opposto :

ucast eth1 10.0.0.1
ucast eth0 192.168.0.8

Heartbeat necessita per la sicurezza della creazione di una chiave di autenticazione :

$ dd if=/dev/urandom count=4 2>/dev/null | md5sum | cut -c1-32
e0fb55565622e3a893a808ee16f70538

Questo comando, da eseguire sulla sola macchina master, produrrà un output il cui contenuto andrà immesso nel file /etc/ha.d/authkeys su entrambe le macchine, con questa struttura :

auth 1
1 sha1 e0fb55565622e3a893a808ee16f70538

Su questo file andranno settati i permessi e la proprietà all’utente cluster :

$ chmod 600 /etc/ha.d/authkeys
$ chown cluster:cluster /etc/ha.d/authkeys

Rimangono quindi da creare due file su entrambi i nodi : il primo nominato “/etc/heartbeat/resource.d/sleep” con questo contenuto :

sleep $1

La cui funzione sarà quella di immettere una pausa (della durata del parametro passato) durante lo switch del servizio. Tale pausa eviterà di incorrere nell’errore “Stale NFS file handle” (per il quale esiste ampia documentazione in internet) che potrebbe influenzare il regolare funzionamento del servizio.
Il secondo file da creare è /etc/heartbeat/resource.d/killnfsd con questo contenuto :

killall -9 nfsd

Che permetterà ad heartbet durante lo switch del servizio di uccidere eventuali processi NFS residui non più controllati.
A questi script appena creati vanno assegnati i permessi di esecuzione :

$ chmod 755 /etc/heartbeat/resource.d/killnfsd
$ chmod 755 /etc/heartbeat/resource.d/sleep

Come ultimo passo per la configurazione, va creato il file /etc/ha.d/haresources, all’interno del quale verranno dichiarate le risorse condivise da heartbeat :

3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3

La struttura del file è molto semplice, viene indicato il nodo master, ossia 3dv-ha-1, l’indirizzo IP virtuale a cui i servizi risponderanno ed i servizi stessi, cioè DRBD, NFS e SAMBA insieme agli script di controllo.
Heartbeat è quindi pronto ad essere avviato :

$ /etc/init.d/heartbeat start

E ne si può seguire l’evoluzione nel file /var/log/ha.log :

$ tail -f /var/log/ha.log
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp
heartbeat: 2006/06/20_18:34:07 received ip-request-resp IPaddr::192.168.0.10/24/eth0 OK yes
heartbeat: 2006/06/20_18:34:07 info: Acquiring resource group: 3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.10/24/eth0 start
heartbeat: 2006/06/20_18:34:07 info: /sbin/ifconfig eth0:0 192.168.0.10 netmask 255.255.255.0   broadcast 192.168.0.255
heartbeat: 2006/06/20_18:34:07 info: Sending Gratuitous Arp for 192.168.0.10 on eth0:0 [eth0]
heartbeat: 2006/06/20_18:34:07 /usr/lib/heartbeat/send_arp -i 1010 -r 5 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp-192.168.0.10 eth0 192.168.0.10 auto 192.168.0.10 ffffffffffff
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/drbddisk drbd0 start
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /store ext3 start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/ha.d/resource.d/killnfsd  start
heartbeat: 2006/06/20_18:34:08 ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/nfs-common  start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/nfs-kernel-server  start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/samba  start
heartbeat: 2006/06/20_18:34:11 info: Running /etc/ha.d/resource.d/sleep 3 start

L’unico errore rilevato (“ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd”) si può ignorare, in quanto non esistono processi residui per NFS e l’esito dell’operazione “killall” è comunque coerente.

Per effettuare un test, da una macchina remota, è possibile montare lo share in NFS :

$ mount -t nfs 192.168.0.10:/store/Progetti /mnt/

Se l’esito del comando mount sarà positivo, si potrà provare a creare un file all’interno dello share:

$ ls -la /mnt/
$ touch /mnt/test-ha

Per effettuare una prova di corretto failover basterà spegnere il nodo master e verificare che lo slave prenda il suo posto e sia quindi altamente affidabile.
Mettendosi “in ascolto” sul file di log della macchina slave e spegnendo il nodo master si può controllare quanto succede :

$ tail -f /var/log/ha.log
heartbeat: 2006/06/20_18:39:51 info: Received shutdown notice from '3dv-ha-1'.
heartbeat: 2006/06/20_18:39:51 info: Resources being acquired from 3dv-ha-1.
heartbeat: 2006/06/20_18:39:51 info: acquire local HA resources (standby).
heartbeat: 2006/06/20_18:39:51 info: local HA resource acquisition completed (standby).
heartbeat: 2006/06/20_18:39:51 info: Standby resource acquisition done [all].
heartbeat: 2006/06/20_18:39:51 info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys 3dv-ha-2] to acquire.
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/rc.d/status status
heartbeat: 2006/06/20_18:39:51 info: Taking over resource group IPaddr::192.168.0.10/24/eth0
heartbeat: 2006/06/20_18:39:51 info: Acquiring resource group: 3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.10/24/eth0 start
heartbeat: 2006/06/20_18:39:51 info: /sbin/ifconfig eth0:0 192.168.0.10 netmask 255.255.255.0   broadcast 192.168.0.255
heartbeat: 2006/06/20_18:39:51 info: Sending Gratuitous Arp for 192.168.0.10 on eth0:0 [eth0]
heartbeat: 2006/06/20_18:39:51 /usr/lib/heartbeat/send_arp -i 1010 -r 5 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp-192.168.0.10 eth0 192.168.0.10 auto 192.168.0.10 ffffffffffff
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/drbddisk drbd0 start
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /store ext3 start
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/killnfsd  start
heartbeat: 2006/06/20_18:39:51 ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/nfs-common  start
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/nfs-kernel-server  start
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/samba  start
heartbeat: 2006/06/20_18:39:55 info: Running /etc/ha.d/resource.d/sleep 3 start
heartbeat: 2006/06/20_18:39:58 info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete.
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete for node 3dv-ha-1.
heartbeat: 2006/06/20_18:40:06 WARN: node 3dv-ha-1: is dead
heartbeat: 2006/06/20_18:40:06 info: Dead node 3dv-ha-1 gave up resources.
heartbeat: 2006/06/20_18:40:23 info: Link 3dv-ha-1:eth1 dead.
heartbeat: 2006/06/20_18:40:23 info: Link 3dv-ha-1:eth0 dead.

Le due righe :

heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete.
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete for node 3dv-ha-1.

confermano che il failover è stato eseguito con successo.
Per il client che montava la cartella remota tutto si è svolto in maniera trasparente, ed il mount point risponde a dovere :

$ ls /mnt/
test-ha

Stessi test possono essere effettuati per SAMBA.
E’ da notare che nel momento in cui si accenderà nuovamente il nodo master, ad erogare il servizio sarà sempre il nodo slave che cederà le risorse solo in caso di spegnimento o di rottura di componenti hardware.

Anche la descrizione di questo progetto viene conclusa con il giudizio della società : “Questo tipo di sistema ci ha permesso di memorizzare la totalità dei dati che gestiamo e di avere la sicurezza nella ridondanza dei dati. A questo si aggiunge il risparmio sensibile dettato dall’hardware impiegato.” – Dario Colombo, Amministratore Delegato di 3Dvision

Conclusioni

Le potenzialità offerte dalla gestione del RAID software da parte del kernel Linux sono notevoli e questa lunga panoramica lo ha dimostrato. Quello che rimane da fare è cercare di spingere il più possibile le aziende a sperimentare queste soluzioni, perché dopo la logica diffidenza iniziale, rimane solo la soddisfazione di aver fatto una scelta che ha portato un incremento della produttività, un risparmio ed un sistema al passo con i tempi.

Bibliografia essenziale

“The Software-RAID HOWTO” di Jakob Østergaard ed Emilio Bueso http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html

“$ man mdadm”

“DRBD”
http://www.drbd.org/

“DRBD : Linux HA”

http://linux-ha.org/DRBD

“$ man drbd.conf”

Ringraziamenti

Questo documento esiste grazie anche ad alcune persone che mi hanno aiutato nei momenti critici. Grazie quindi a Lorenzo Panarello per le revisioni, al Morby per i consigli sull’applicazione pratica dei RAID ed a mia moglie per la pazienza, in quanto credo che ormai in fatto di RAID ne sappia più di me.

RAID Software : Proteggere i dati con l’aiuto del kernel (4 di 5)

Raoul Scarazzini — Tue, 31 Mar 2009 08:19:29 +0000

Nel precedente articolo è stato affrontato l’argomento della messa in RAID della partizione di root, partendo da un’installazione standard o da un sistema già esistente.
In questa penultima parte della serie viene affrontato un case study relativo all’impiego di mdadm per la creazione di un sistema RAID 1 con disco estraibile.

Case Study 1 – RAID 1 con HD ide “a cassetto”

Il seguente Case study descrive il progetto realizzato per la società “Immagine & Dettaglio” che si occupa di architettura d’interni, progettazione architettonica e di grafica.
L’esigenza primaria della società era di ottenere la gestione centralizzata dei dati e rimpiazzare il vetusto impianto per i backup, rappresentato da un DAT (Digital Audio Tape) a cassette, con un progetto che offrisse maggiore sicurezza nella registrazione dei dati, minori costi e la possibilità di trasportare tali backup in luoghi diversi dall’ufficio in cui risiedeva il sistema, per ridurre al minimo la possibilità di perdita totale di tutti i dati.
Il progetto ha quindi previsto il riutilizzo di una vecchia macchina (denominata “ied-storage” con processore Intel Celeron 1000 MegaHertz, 256 MegaByte di RAM ed un disco da 20 GigaByte), l’acquisto di tre dischi IDE da 300 GigaByte e due kit per hard disk estraibili.
Questi kit, visibili nella Foto 1 risultano facilmente installabili in qualsiasi slot da 5 pollici e ¼ (ossia lo slot dei lettori cd/dvd) e consentono di collegare un cassetto ad uno dei canali IDE della scheda madre e di rendere il disco che viene inserito all’interno di questo, estraibile.

Foto 1

Sul canale IDE primario della scheda madre sono stati quindi collegati il disco del sistema operativo da 20 GigaByte (come Master) ed il lettore DVD (come Slave) mentre sul canale IDE secondario è stato collegato uno dei dischi da 300 GigaByte (come Master) ed il cassetto IDE (come Slave).
Utilizzando la tecnologia RAID software offerta dal kernel Linux per realizzare un mirror (RAID 1) sui dischi collegati al secondo canale IDE oltre ad avere 300 GigaByte di spazio disponibile in rete, ne si garantisce il completo backup.
Inoltre, attraverso delle sostituzioni schedulate del disco (ad esempio una volta la settimana), si garantisce la possibilità di trasportare il contenuto del disco lontano dall’ufficio, avere tre copie dello stesso dato ad ogni sostituzione e nella peggiore delle ipotesi, ossia quella in cui entrambi i dischi collegati alla macchina si rompano, una sola settimana di ritardo nei backup (presenti sul disco estratto la settimana precedente).
Sul disco primario da 20 GigaByte è stato installato come sistema operativo Debian Sarge 3.1, mentre i due dischi hdc e hdd non sono stati configurati.

Sviluppo del progetto

Lo stato del sistema al primo boot è il seguente:

$ df -h
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/hda2            19,2G 1001M 17,8G  12% /
tmpfs                 443M     0  443M   0% /dev/shm

Una partizione root da 19 GigaByte, una swap da 500 MegaByte.
Su ciascuno dei due dischi hdc e hdd vanno quindi create due partizioni hdc1 ed hdd1 (ad esempio attraverso il programma fdisk) della massima grandezza disponibile (quindi 300 GigaByte) ed il RAID 1 ad esse associato:

$ mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/hdc1 /dev/hdd1
mdadm: array /dev/md0 started.

Al termine della sincronizzazione lo stato del RAID è il seguente:

$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdd1[1] hdc1[0]
      2993440 blocks [2/2] [UU]
 
unused devices:

La fase successiva prevede la creazione del filesystem sulla device md0:

$ mke2fs -j /dev/md0

Ed il suo montaggio nella directory /mnt:

$ mount /dev/md0 /mnt

In questo modo è possibile muovere l’attuale contenuto della cartella /home all’interno del nuovo filesystem, questo perché l’obiettivo finale vuole essere quello di rendere lo spazio offerto dal RAID 1 condiviso attraverso SAMBA, che nella configurazione standard condivide le directory home di ciascun utente:

$ mv /home/* /mnt/

Una volta smontata la cartella /mnt:

$ umount /mnt/

E’ possibile associare all’interno del file /etc/fstab la device /dev/md0 al mount point /home, aggiungendo nel file /etc/fstab la seguente riga:

/dev/md0        /home           ext3    defaults        0       0

E forzarne il mount con il comando mount -a, verificando che sia poi correttamente montata:

$ mount -a
$ mount
...
...
/dev/md0 on /home type ext3 (rw)

Configurazione di SAMBA

Nell’installare SAMBA come prima cosa, all’interno del file /etc/apt/sources.list di entrambe le macchine, vanno aggiunti i repositories SAMBA per le ultime versioni:

deb http://it.samba.org/samba/ftp/Binary_Packages/Debian sarge samba

In questo modo pur utilizzando una distribuzione stabile (Sarge) i cui pacchetti relativi a SAMBA sarebbero aggiornati a versioni precedenti alle ultime disponibili, si potrà disporre dei pacchetti allo stato dell’arte.
Effettuata la modifica, è necessario lanciare l’aggiornamento dei repositories:

$ apt-get update

Quindi installare SAMBA lasciando il file di configurazione così com’è, in modo che condivida le cartelle homes di tutti gli utenti (configurazione di default):

$ apt-get install samba smbfs smbclient

Una volta creato un utente locale nel sistema ed in SAMBA:

$ adduser ied-user1
$ passwd ied-user1
$ smbpasswd -a ied-user1

Lo spazio presente nel RAID 1 è accessibile dai client Microsoft Windows della rete che effettuino il login con l’utenza “ied-user1”.

Sostituire il disco estraibile

A completamento del progetto, rimane da schedulare uno spegnimento forzato della macchina necessario alla sostituzione del disco. Inutile dire che il disco non può essere estratto a caldo, pertanto si è stato scelto di spegnere la macchina ogni venerdì, manualmente o attraverso la schedulazione del crontab sostituendo il disco prima di riaccenderla. L’unico accorgimento che va preso in questo senso riguarda la forzatura dell’aggiunta del nuovo disco esterno all’interno del RAID. La motivazione è che controller software del kernel, trovandosi un persistent superblock differente sul disco che è stato sostituito, giudica il RAID in stato inconsistente.
Per ovviare, è sufficiente fare in modo che ad ogni avvio di sistema venga lanciato il seguente comando:

$ mdadm -a /dev/md0 /dev/hdd1

Tale comando nel caso che il disco non cambi non effettuerà alcuna operazione, giudicando il disco “already added”, nel caso che il disco ed il persistent superblock siano differenti, lo aggiungerà avviandone in contemporanea la re sincronizzazione, operazione che impiegherà per una capacità di 300 Giga circa 100 minuti.
Il comando lanciato può essere incluso in uno script denominato ad esempio /etc/init.d/mdadm-raid-recovery, dal seguente contenuto:

#!/bin/bash
#
# Script per il recovery del secondo disco di RAID.
 
mdadm -a /dev/md0 /dev/hdd1

Ed incluso fra gli script di avvio in questo modo:

$ update-rc.d mdadm-raid-recovery start 20 2 3 4 5 .
 Adding system startup for /etc/init.d/mdadm-raid-recovery ...
   /etc/rc2.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc3.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc4.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc5.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery

ad ogni avvio del sistema verrà effettuato questo controllo e l’eventuale aggiunta del disco inserito.
In caso sia presente un nuovo disco, verrà sincronizzato e messo in linea, di modo da garantire, al momento della sostituzione e prima di qualsiasi altra nuova scrittura, tre copie identiche dello stesso dato.

Ecco il giudizio sul progetto espresso dalla società : “L’utilizzo di un backup come questo ci ha permesso di avere la totale sicurezza per i dati e la possibilità di conservare una copia di essi lontano dalla sede. A tutto questo si aggiunge il risparmio dovuto al fatto di aver usato una macchina dismessa insieme all’acquisto dei tre dischi e dei relativi kit.” – Luciana Ferrari, Amministratore unico di “Immagine & Dettaglio”

Conclusioni

Nel prossimo ed ultimo articolo verrà illustrato il secondo case study: un network RAID 1 attraverso DRBD.

Note

Questa serie di articoli è apparsa in origine nel libro edito da Duke Italia Clustering e raid software allegato all’edizione italiana di Linux Journal dell’Ottobre 2006.

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools (6 di 6)

Raoul Scarazzini — Mon, 04 Feb 2008 00:04:18 +0000

Terminata la fase delle configurazioni è tempo di concludere la trattazione dell’argomento PDC su Linux con la creazione della prima utenza ed il primo accesso da un client Microsoft Windows.

Creazione utenze e primo login

Prima di effettuare il login da una macchina Windows è necessario creare sul PDC Linux la prima utenza attraverso il comando smbldap-useradd:

$ smbldap-useradd -P -a -m -c "SMBLDAP Test user" smbldaptest
Changing UNIX and samba passwords for smbldaptest
New password:
Retype new password:

I parametri passati al comando servono a richiedere una password per l’utenza (-P), a specificare che l’utenza è di tipo Windows (-a), a far creare la home directory dell’utente ed infine a definire la descrizione (-c).

L’utenza è creata e non rimane altro da fare che provare ad effettuare il login da Windows. La prima cosa da fare è aggiungere la macchina al dominio. Per fare questo è necessario accedere alle proprietà del computer e nella sezione “Nome computer” cliccare sul tasto “Cambia…”:

Figura 1

Verrà quindi contattato il PDC Linux e dopo aver indicato le credenziali dell’utente Administrator:

Figura 2

l’aggiunta della macchina al dominio verrà confermata dal messaggio:

Figura 3

Una volta effettuato il reboot, sarà possibile selezionare in fase di login il dominio a cui fare riferimento:

Figura 4

Per verificare che le informazioni relative all’ambiente vengono registrate sul PDC Linux è possibile ad esempio creare una directory sul desktop e sullo stesso copiare un file immagine, impostandolo come sfondo:

Figura 5

Dopo aver effettuato il logout che salverà i dati del client sul PDC:

Figura 6

Sarà possibile controllare sul server l’effettiva creazione dell’ambiente e dell’immagine specifica nel path:

$ ls -la /home/samba/profiles/smbldaptest/Desktop
totale 352
drwx------  3 smbldaptest Domain Users   4096 2007-11-21 13:13 .
drwx------ 13 smbldaptest Domain Users   4096 2008-01-09 10:11 ..
drwx------  2 smbldaptest Domain Users   4096 2007-05-14 17:52 Cartella remota
-rw-------  1 smbldaptest Domain Users 343073 2007-11-21 13:13 Moz_ffx_openStandards_1024x768.jpg

Da ogni client aggiunto al dominio sarà possibile collegarsi con l’utenza smbldaptest ritrovando ogni volta le stesse impostazioni e gli stessi dati. Il progetto può dirsi quindi completo.

Siti ufficiali

SAMBA: http://www.samba.org
OpenLDAP: http://www.openldap.org/
SMBLDAP Tools: https://gna.org/projects/smbldap-tools/

Bibliografia

http://www.pluto.it/files/journal/pj0605/samba3pdc.html
http://openskills.info/infobox.php?ID=552

La serie comprende questi articoli :

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools (5 di 6)

Raoul Scarazzini — Mon, 28 Jan 2008 00:05:17 +0000

Per terminare la configurazione del sistema non rimane che impostare SAMBA in modo che possa comunicare con il direttorio LDAP.

Configurazione di SAMBA

Il file di configurazione è /etc/samba/smb.conf e le parti da modificare sono essenzialmente quelle riguardanti il nome ed il tipo di accesso al dominio. Partendo dalla sezione global andranno indicate le informazioni per l’identificazione del server SAMBA:

workgroup = TESTLAN.LOCAL
netbios name = PDC
server string = %h server
wins support = yes
dns proxy = no

La tipologia ed il backend per l’accesso alle informazioni:

security = user
encrypt passwords = true
passdb backend = ldapsam:ldap://127.0.0.1
obey pam restrictions = yes
invalid users = root
unix password sync = no

Relativamente alle informazioni di dominio, andrà indicato a SAMBA di supportare il login da parte dei client e quali condivisioni dovranno montare localmente questi per ricreare l’ambiente che risiede sul server:

domain logons = yes
logon path = \%Nprofiles%U
logon drive = H:
logon home = \%N%U
logon script = logon.cmd

Ed a completare la configurazione delle autenticazioni, andranno inserite tutte le informazioni relative al direttorio LDAP, partendo dalla configurazione del backend, sino all’abilitazione dei client Windows alla modifica delle informazioni del database tramite i comandi della suite smbldap:

socket options = TCP_NODELAY
domain master = yes
 
ldap admin dn = cn=admin,dc=testlan,dc=local
ldap suffix = dc=testlan,dc=local
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
 
ldap passwd sync = Yes
passwd program = /usr/sbin/smbldap-passwd %upasswd chat = *New*password* %nn *Retype*new*password* %nn *all*authentication*tokens*updated*
add user script = /usr/sbin/smbldap-useradd -m "%u"
ldap delete dn = Yes
delete user script = /usr/sbin/smbldap-userdel "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"

Infine nella definizione delle condivisioni andranno abilitate le home di ciascun utente, la directory contenente gli (eventuali) script che verranno eseguiti al login ed infine la directory contenente i file relativi al profilo:

[homes]
comment = Home Directories
browseable = no
writable = yes
create mask = 0700
directory mask = 0700
 
[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
writable = no
share modes = no
 
[profiles]
comment = Users profiles
path = /home/samba/profiles
read only = no
create mask = 0600
directory mask = 0700

A questo punto va impostata la password con la quale il server SAMBA accede al direttorio LDAP:

$ smbpasswd -w 
Setting stored password for "cn=admin,dc=testlan,dc=local" in secrets.tdb

E prima del fatidico avvio del servizio SAMBA, andranno create le directory alle quali il file di configurazione fa riferimento (con i relativi permessi):

$ mkdir -p /home/samba/netlogon
$ mkdir /home/samba/profiles
$ chmod 1757 /home/samba/profiles

Tutto è pronto per l’avvio del servizio attraverso lo script presente nella directory /etc/init.d:

$ /etc/init.d/samba start
Starting Samba daemons: nmbd smbd.

Il sistema è pronto ad accogliere le richieste dei client Windows.

Nel prossimo (ed ultimo) articolo verrà descritta la procedura per creare delle utenze nel PDC e l’aggiunta di client Microsoft Windows al dominio.

La serie comprende questi articoli :

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Gennaio 2008.

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools (4 di 6)

Raoul Scarazzini — Thu, 24 Jan 2008 00:05:10 +0000

La struttura logica dell’alberatura OpenLDAP per il PDC è stata creata e va configurato il metodo di accesso del sistema alle informazioni registrate nel direttorio tramite libnssl-dap.

Configurazione di libnsss-ldap

Prima di concludere il progetto con la configurazione di SAMBA ed effettuare i test di aggiunta al dominio di client Microsoft Windows esiste un ultimo pacchetto da configurare: il modulo NSS (Name Service Switch) relativo a LDAP. Tale modulo consentirà al sistema di reperire dal server LDAP le informazioni degli account, dei gruppi, degli host e tutto quanto è generalmente ottenibile dalle interrogazioni dei file presenti nella directory /etc.
Per installare il modulo è sufficiente digitare il comando:

$ apt-get install libnss-ldap

durante l’installazione verranno richiesti i dati relativi al server LDAP che verrà utilizzato per le interrogazioni, quindi l’indirizzo (ldap://127.0.0.1/), il suffisso di partenza per le ricerche (dc=testlan,dc=local), la versione del protocollo LDAP da usare (3) ed infine il nome dell’account con cui verranno effettuate le interrogazioni al directory server (cn=admin,dc=testlan,dc=local). Una volta indicata la password relativa all’account admin, l’installazione sarà terminata. Andrà quindi indicato al sistema che le informazioni relative agli account andranno ricercate oltre che localmente anche nel direttorio LDAP. Questo si ottiene modificando nel file /etc/nsswitch.conf le righe relative a passwd, group e shadow in questo modo:

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

La verifica di quanto fatto è ottenibile attraverso il comando getent, un comando che riceve informazioni dai database di sistema :

getent passwd
...
...
...
Administrator:x:0:0:Netbios Domain Administrator:/home/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false

L’output del comando mostra come oltre alle utenze contenute nel file di sistema /etc/passwd vengano elencate anche le due utenze create dal popolamento del database LDAP attraverso il comando smbldap-populate.

Nel prossimo articolo verrà descritta nel dettaglio la configurazione di SAMBA e la conseguente integrazione del pacchetto nell’ambiente che è stato creato.

La serie comprende questi articoli :

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Gennaio 2008.

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools (3 di 6)

Raoul Scarazzini — Mon, 21 Jan 2008 00:05:24 +0000

La configurazione di Openldap è completa ed è tempo di dedicare l’attenzione alla creazione della struttura logica del Primary Domain Controller attraverso le smbldap-tools.

Configurazione di smbldap-tools

Le utility presenti nel pacchetto smbldap-tools fanno riferimento ai parametri impostati in due file che andranno copiati nella directory /etc/smbldap-tools :

$ cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /etc/smbldap-tools/
$ zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > /etc/smbldap-tools/smbldap.conf

Il primo file andrà compilato con le informazioni di accesso al direttorio LDAP :

slaveDN="cn=admin,dc=testlan,dc=local"
slavePw="passwordsegreta"
masterDN="cn=admin,dc=testlan,dc=local"
masterPw="passwordsegreta"

Essendo le password digitate in chiaro, il file andrà protetto, proibendo l’accesso in lettura e scrittura da chiunque non sia root :

$ chmod 600 /etc/smbldap-tools/smbldap_bind.conf

All’interno del secondo file andranno indicate le informazioni relative al dominio che le utility andranno ad amministrare.
Essenziale nella compilazione del file è il reperimento del SID, acronimo che significa Security ID (Identificativo di sicurezza), ossia una chiave che identifica univocamente i
l dominio amministrato da SAMBA :

$ net getlocalsid
SID for domain PDC is: S-1-5-21-3200784789-215075224-1452583727

Questo dato andrà inserito nel file di configurazione alla voce relativa insieme al nome del dominio che sceglieremo, nel nostro caso come per il suffisso sarà TESTLAN.LOCAL :

SID="S-1-5-21-3200784789-215075224-1452583727"
sambaDomain="TESTLAN.LOCAL"

lasciando il default per quanto indicato negli IP in ascolto e nelle relative porte, andrà modificato il parametro relativo ai certificati di sicurezza, che non utilizzeremo :

ldapTLS="0"

andranno poi indicati il suffisso del dominio LDAP ed il nome del dominio SAMBA nei parametri suffix e sambaUnixIdPooldn :

suffix="dc=testlan,dc=local"
sambaUnixIdPooldn="sambaDomainName=TESTLAN.LOCAL,${suffix}"

Ed infine i dati relativi ai Roaming Profiles. Il Roaming Profile (letteralmente Profilo Vagante) è utilizzato per preservare la configurazione dell’utente (le impostazioni del desktop, lo sfondo, etc) e permette a quest’ultimo di avere il medesimo ambiente in qualsiasi computer effettuerà un login.
Ad occuparsi della memorizzazione lato server di questi dati ci sarà SAMBA, attraverso la configurazione che vedremo più avanti. I dati che interessano i roaming profile nel file di configurazione sono i seguenti :

userSmbHome="\PDC%U"
userProfile="\PDCprofiles%U"
userHomeDrive="H:"
userScript="logon.bat"

come si può notare vengono indicati la cartella home utente, la cartella relativa al nome del profilo, il nome dell’unità con cui la cartella verrà mappata in locale sui client Microsoft Windows ed il nome dello script che verrà eseguito ad ogni login (che salvo esigenze particolari, può essere vuoto).

Terminata la modifica del file si può procedere con il popolamento dell’alberatura LDAP secondo lo schema proprio dei PDC Microsoft attraverso lo script smbldap-populate, al quale verrà passato il parametro -k che indicherà l’ID da associare all’amministratore del direttorio, cioè 0, l’id di root nei sistemi Linux ed il parametro -a che specificherà il nome dell’utenza amministratrice che verrà settata seguendo lo standard dei PDC Microsoft Windows ad Administrator :

smbldap-populate -a Administrator -k 0
Populating LDAP directory for domain TESTLAN.LOCAL (S-1-5-21-3200784789-215075224-1452583727)
(using builtin directory structure)
 
entry dc=testlan,dc=local already exist.
adding new entry: ou=Users,dc=testlan,dc=local
adding new entry: ou=Groups,dc=testlan,dc=local
adding new entry: ou=Computers,dc=testlan,dc=local
adding new entry: ou=Idmap,dc=testlan,dc=local
adding new entry: uid=Administrator,ou=Users,dc=testlan,dc=local
adding new entry: uid=nobody,ou=Users,dc=testlan,dc=local
adding new entry: cn=Domain Admins,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Domain Users,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Domain Guests,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Domain Computers,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Administrators,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Account Operators,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Print Operators,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Backup Operators,ou=Groups,dc=testlan,dc=local
adding new entry: cn=Replicators,ou=Groups,dc=testlan,dc=local
adding new entry: sambaDomainName=TESTLAN.LOCAL,dc=testlan,dc=local
 
Please provide a password for the domain Administrator:
Changing UNIX and samba passwords for Administrator
New password:
Retype new password:

Una volta digitata la password richiesta per l’utente Administrator, che come vedremo in seguito risulterà essenziale per aggiungere client Microsoft Windows al dominio, la creazione dell’alberatura sarà completa.

Nel prossimo articolo verrà descritta l’installazione del pacchetto libnss-ldap che interfaccerà il sistema con il direttorio Openldap appena creato.

La serie comprende questi articoli :

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.