Samba,CupseNetatalk:condivisionedirisorseinambitoLinux UNIVERSITÁDEGLISTUDIDIMODENAEREGGIOEMILIA

Facoltà di Ingegneria - Sede di Modena Corso di Laurea in Ingegneria Elettronica

Samba, Cups e Netatalk:

condivisione di risorse in ambito Linux

Relatore: Tesi di Laurea di:

Prof.ssa Letizia Leonardi Luca Martinelli

Correlatore:

Ing. Luca Ferrari

Anno Accademico 2003 - 2004

Indice

1 Samba 3

1.1 Introduzione . . . . 3

1.2 Caratteristiche . . . . 7

1.3 Funzionamento: una generica sessione Samba . . . 10

1.3.1 Concetti di Windows Networking . . . 10

1.3.2 File sharing & print sharing . . . 11

1.3.3 Samba Printing . . . 12

1.4 Analisi pacchetti . . . 14

1.4.1 Netbios e Netbeui . . . 15

1.4.2 Autenticazione . . . 18

1.4.3 Dettaglio pacchetti . . . 19

1.5 Esempio di congurazione di Samba . . . 25

1.6 Applicazioni che costituiscono Samba . . . 32

1.7 Evoluzione di Samba: CIFS . . . 37

2 Netatalk 39 2.1 Introduzione . . . 39

2.2 AppleTalk e lo standard ISO/OSI . . . 39

2.2.1 Una implementazione del protocollo Appletalk . . . . 49

2.3 Compilazione e installazione di Netatalk . . . 49

2.4 Congurazione di Netatalk . . . 50

2.4.1 Congurazione di AppleTalk Routing . . . 51

2.4.2 Congurazione di un File Server . . . 54

2.4.3 Principali Utility di Netatalk . . . 57

3 Cups 60 3.1 Introduzione . . . 60

3.1.1 Introduzione a IPP . . . 60

3.2 Concetti generali . . . 62

3.2.1 PostScript . . . 62

3.2.2 RIP . . . 63

3.2.3 Spooler e Demoni di Stampa . . . 64

3.2.4 File PPD . . . 64

1

3.4 Scheduler . . . 66

3.5 Conguration File . . . 66

3.5.1 Congurazione del server HTTP . . . 66

3.5.2 File di congurazione per stampanti . . . 67

3.5.3 Tipologie MIME supportate . . . 71

3.6 CUPS API . . . 71

3.7 Berkeley and System V Commands . . . 74

3.7.1 lpstat . . . 74

3.7.2 lp status . . . 75

3.7.3 lpc status . . . 75

3.7.4 lpq . . . 75

3.7.5 lprm e cancel . . . 75

3.7.6 lpadmin . . . 75

3.7.7 cupsaddsmb . . . 76

3.7.8 lpinfo . . . 76

3.8 Filters . . . 76

3.8.1 foomatic . . . 77

3.8.2 pap . . . 77

3.9 CUPS Imaging . . . 77

3.10 Backends . . . 78

3.10.1 Samba Backend . . . 78

3.11 Network Printing . . . 81

Bibliograa 86

Samba

1.1 Introduzione

Samba e` un progetto fondato nel 1991 da Andrew Tridgell, al quale oggi- giorno contribuiscono attivamente una decina di sviluppatori. Samba è Soft- ware Libero distribuito con licenza GPL [1]. Questo software rende traspar- ente l'integrazione tra Unix e Windows, poichè Samba funziona bene su molte piattaforme (GNU/Linux, Mac Os-X, Solaris, HP-UX, AIX, True64,

*BSD, e altre ancora), implementando un server SMB. SMB è un famoso protocollo di condivisione delle risorse adottato sul nire degli anni Ottanta da molti produttori per fornire funzionalità di condivisione di le, directory e stampanti all'interno di una rete locale. Tra questi produttori c'era anche Microsoft, che decise di includere il protocollo all'interno del suo sistema operativo Windows per l'erogazione dei servizi di rete. La scelta si rivelò strategica per la casa di Redmond che raorzò il supporto a SMB in tutte le release successive dei propri sistemi operativi. Oggi SMB è più che mai pre- sente nei sistemi Microsoft anche se recentemente ha cambiato il suo nome in CIFS (Common Internet File System)[2].

Un Protocollo onnipresente Come conseguenza naturale dell'adozione di SMB da parte di Microsoft, attualmente esistono svariati milioni di com- puter Windows che fanno uso di questo protocollo, creando così uno standard di fatto per i servizi di condivisione delle risorse. Ogni volta che si clicca sul- l'icona di Risorse di Rete oppure ogni volta che si lancia una stampa su una unità condivisa da Windows, si sta in qualche modo utilizzando il protocollo SMB. Nonostante la presenza quasi esclusiva in ambito Windows, SMB è un protocollo aperto e non un sistema chiuso sotto la proprietà di Microsoft.

Qualunque produttore o gruppo di sviluppo può implementarlo per fornire servizi di condivisione su qualunque sistema e piattaforma, garantendo una piena compatibilità Windows. Questo è proprio quello che fa il progetto Samba: fornire servizi di condivisione per accedere in maniera trasparente

3

go tempo ma si può certamente aermare che la diusione più rilevante di Samba si ha con la versione 2.2 nella piattaforma Linux. Il successo è stato dato dalla credibilità del sistema operativo stesso e dall'allettante possibilità di replicare quasi completamente le funzionalità di un server Windows NT4 senza sostenere costi di licenza. Installando Samba in un le server era pos- sibile risparmiare subito circa mille euro di licenza Windows Server più tutte le CAL[3]

richieste per ogni client che accede ai servizi centralizzati. Un vantaggio non indierente per piccole e medie imprese, organizzazioni senza scopo di lucro ed enti governativi.

Panoramica di Samba 2.2 La versione 2.2 di Samba funziona grazie a due demoni generalmente attivati in fase di avvio dal sistema operativo. Si tratta di smbd e di nmbd. Il primo provvede alle funzioni di autenticazione e di condivisione delle risorse. Il secondo implementa invece i servizi di risoluzione dei nomi, compreso WINS (Windows Internet Naming Service)

e le funzioni di browsing necessarie per l'elenco dei computer in Risorse di Rete. Non bisogna infatti dimenticare che questo elenco non è dinamico e neppure aggiornato in tempo reale, ma è piuttosto mantenuto da un comput- er sulla rete. Questo a intervalli regolari provvede ad aggiornare l'elenco in base a un algoritmo ben denito. I client fanno riferimento a questo elenco per visualizzare l'elenco dei membri della rete locale. E' per questo motivo che non sempre si riesce a vedere in rete un computer appena acceso o si trovano ancora in elenco computer che risultano invece spenti già da diversi minuti. I demoni smbd e nmbd svolgono nel complesso la totalità delle fun- zioni presenti in Samba 2, garantendo un comportamento simile a quello di un server Windows NT4. Samba 2.2 può svolgere funzioni di workgroup o di PDC, può autenticare gli utenti in modalità debole compatibile Windows 9x, può autenticare in modalità NT, supporta la browsing list e gestisce in buona misura i criteri di sistema, come verrà spiegato in seguito. Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password (SAM)

: quando un client cerca di accedere alle risorse di un serv- er, quest'ultimo verica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l'accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse accessibili. Il database delle password viene automaticamente copiato ad uno o più Backup Domain Controller (BDC) eventualmente pre-

1

Nei modelli di licensing Windows Server è necessaria una licenza Server per ogni copia del software server installata, oltre a una licenza CAL (Client Access License) per ogni utente o dispositivo che accede o utilizza il software server.

2

Il servizio che nelle reti Microsoft viene utilizzato per la traduzione dei nomi in indirizzi.

3

Security Account Manager: sistema per la memorizzazione delle password e dati

account utente in un dominio Microsoft

senti nella rete i quali possono essere utilizzati per autenticare i client nel caso in cui il PDC risulti inaccessibile. Sul server si possono poi congurare un numero arbitrario di condivisioni e creare tutti i presupposti per l'erogazione di cartelle pubbliche e di home directory, tutte protette con diritti a livello di utente. Quanto basta insomma per sostituire un server NT4 in molte situazione reali. La congurazione e la manutenzione del sistema Samba avviene, secondo la tradizione Unix, tramite le testuali da editare man- ualmente. Esistono comunque strumenti graci per semplicare la gestione di Samba. Tra questi è interessante Swat, un front-end Web per l'ammin- istrazione del sistema, che verrà analizzato in seguito. Pur essendo molto funzionale, Samba 2.2 è comunque privo di alcune caratteristiche importan- ti. Non è per esempio contemplato il ruolo di BDC, non sono supportate le relazioni di ducia tra server Windows e server Samba e non è possibile amministrare la lista degli utenti e dei gruppi usando il tool di gestione di Windows NT4. Il divario si è poi allargato, dal momento che Microsoft non si è fossilizzata sulle caratteristiche di Windows NT4, ma ha incrementato piuttosto la rosa di funzionalità di rete nelle successive release di Windows 2000 Server e Windows Server 2003.

La versione corrente: Samba 3 Gli equilibri sono stati nuovamente ripristinati con Samba 3, rilasciato nel settembre 2003. Questa versione ha colmato un elevato numero di carenze, guadagnando nuovamente terreno sull'oerta Microsoft e tornando nuovamente a essere un'alternativa interes- sante. Il progetto è stato in seguito aggiornato no all'attuale 3.0.8. Queste release successive hanno comunque avuto solo ruoli correttivi nei confronti di bug strutturali o di falle di sicurezza[4]. Con questa versione delle suite Samba è stata aggiunta una funizionalità importante il supporto per Active Directory

. Si tratta della possibilità di unirsi come membro a una strut- tura ADS (Active Directory Service) preesistente, con la facoltà di autenti- care utenti tramite il protocollo Kerberos e di utilizzare LDAP (Lightweight Directory Access Protocol)

per la memorizzazione delle informazioni di rete.

Tutto questo è un notevole passo in avanti, ma permangono alcuni limi- ti rilevanti. Occorre innanzitutto spiegare che i protocolli che regolano il funzionamento dei domini Windows non sono in realtà aperti, ma sono un segreto industriale ben custodito da Microsoft, e quindi non esiste quindi alcuna documentazione tecnica liberamente disponibile. Gli sviluppatori di Samba non possono fare altro che compiere esperimenti sui domini ed esam- inare il traco di rete per cercare di dedurre il comportamento dei protocolli.

Si tratta di un estenuante lavoro di reverse engineering.

4

Active Directory Service: il servizio di directory Microsoft. Network Directory è una struttura organizzativa delle le risorse all'interno di una rete (utenti, autenticazioni, condivisioni, stampanti) gestita in modo centralizzato[5].

5

LDAP è un insieme di speciche per un protocollo client-server per ottenere

memorizzare informazioni centralizzate come Network Directory[6].

completamente l'ambiente di Active Directory, in Samba 3 sono state svilup- pate anche le caratteristiche di dominio NT4. La scelta è derivata dalla seguente motivazione: esiste ancora una percentuale elevata di utenti NT4 Server, addirittura superiore alle previsioni di Microsoft, ed è bene fornire supporto a questa categoria di utilizzatori. Bisogna considerare che la mag- gior parte delle PMI (Piccole e Media Industrie) non ha bisogno di tutte le caratteristiche evolute di rete introdotte a partire da Windows 2000 Server.

Un ambiente aperto, senza costi di licenza e in grado di emulare Windows NT4 Server è già più che suciente per una consistente fetta di mercato.

Samba 3 permette di migrare completamente un ambiente NT4 Server man- tenendo le informazioni sugli utenti e sui gruppi, in questo processo vengono preservati anche i SID (Single Identier), gli identicatori unici Windows di sicurezza per gli oggetti gestiti sul server. Grazie a questa capacità i client potranno essere integrati in maniera trasparente e senza alcun lavoro sup- plementare. E' supportato sia il ruolo di PDC (presente già da tempo) che quello di BDC, una novità per Samba. I tool di amministrazione presenti su Windows possono essere usati per amministrare questo ambiente, rendendo più semplice la gestione da parte dello sta tecnico.

I domini creati con Samba non sono isolati, ma possono istituire relazioni di ducia con controller di dominio basati su Windows. Questa era una delle carenze più sentite in Samba 2.2, in quanto l'assenza delle trust impediva l'uso di Samba in realtà complesse dotate di molti domini. I nomi delle risorse possono essere composti ora in maniera più cosmopolita grazie all'inclusione di unicode: esiste ora piena facoltà di avere nomi realmente internazionali con alfabeti non occidentali. E' inne degna di nota la scelta di introdurre un comando net ispirato all'omonimo comando Windows per l'esecuzione di un gran numero di funzioni di rete. L'obiettivo dichiarato è quello di sostituire progressivamente la miriade di utility e comandi di supporto a Samba con le opzioni incorporate all'interno dell'unico comando net. Si tratta di una scelta interessante, che permette di semplicare la gestione del sistema con un numero limitato di istruzioni da linea di comando.

Samba 3 può essere a tutti gli eetti considerato una implementazione lib- era e gratuita del protocollo SMB/CIFS, con esso, una macchina GNU/Linux, può accedere alle risorse condivise di un elaboratore MS-Windows ma anche mettere a disposizione proprie risorse a clienti MS-Windows o GNU/Linux.

Più in dettaglio ecco quali sono i servizi oerti da Samba: :

• server per orire la condivisione di le system e stampanti;

• client per l'accesso a risorse NetBIOS su macchine Unix, MS-Windows, Novell remote;

• master browser (sia locale che di dominio);

• server WINS (Windows internet name service);

• server per l'autenticazione di clienti di un dominio MS-Windows.

1.2 Caratteristiche

Le caratteristiche principali oerte da Samba sono:

Integrazione In molti scenari sono utilizzati ambienti eterogenei con serv- er e client di diversa natura. E spesso è necessario far dialogare questi sistemi.

Molto spesso inoltre i client sono Windows, mentre i server sono di dieren- ti tipologie Unix, Novell, NT eccetera. Samba permette di integrare server GNU/Linux, BSD, o Unix (e altri) in una rete in cui si deve convivere con client MS Windows senza dover installare software aggiuntivo sui client. Il server Samba viene percepito come un server Windows NT e consente di condividere le e stampanti su una rete Windows senza troppi sforzi. Samba è inoltre ottimo come server di stampa, accopiato a CUPS o lpr permette anche un sistema essibile e avanzato di accounting delle stampe, ad esem- pio consentendo a macchine Windows di utilizzare stampanti installate su macchine *niX o viceversa a macchinue *niX di stampare su risorse collegate a sistemi Windows.

Costo Samba viene utilizzato spesso per permettere ai client Windows di

vedere i le residenti su sistemi tipo *niX e permettere in questo modo alle piattaforme Windows di interoperare con le piattaforme server. Samba viene però anche sempre più utilizzato in sostituzione di File Server NT o Novell in quanto permette di ridurre sensibilmente i costi di licenza per l'accesso dei client e ottenere un'alta adabilità del servizio. Infatti molti sistemi le server/print server/domain controller proprietari richiedono oltre al paga- mento di una licenza d'uso per il server in sè, anche di licenze di connessione per ogni client che deve utilizzare tale server (CAL). Molte aziende possono permettersi di impiegare un server basato sull'accoppiata Linux/Samba, in quanto le eettive necessità centralizzate sono generalmente limitate. Non bisogna dimenticare che gran parte dei server NT o 2000 vengono utilizzati solamente per le loro funzionalità di le server. In pratica si sfrutta il sistema come contenitore centralizzato dove salvare i documenti di lavoro e le cartelle personali degli utenti, impiegando poi un sistema di storage per eseguire il salvataggio di tutta l'informazione aziendale in un colpo solo.

Queste funzionalità sono estremamente preziose per la miriade di PMI che popolano lo scenario industriale italiano, anche se in n dei conti si tratta di necessità tecnologiche molto semplici [9].

L'economicità di un sistema GNU/Linux riguarda soprattutto i requisiti

hardware richiesti: GNU/Linux gira anche su hardware cosiddetto ob-

soleto. Ciò si traduce in un risparmio economico poichè non sono neces-

sari frequenti aggiornamenti hardware. È stimato, infatti, che la vita me-

dows richiede in media il raddoppio delle risorse hardware di versione in versione)[10].

Flessibilità Samba facilita le operazioni di consolidazione di più servizi su un singolo server. E' possibile anche congurare più istanze di Samba su un server che abbia più interfacce di rete. Non solo, Samba è già predisposto per IP failover

, ed è estremamente essibile e dotato di un numero eccezionale di opzioni con cui ottimizzare il proprio server e congurarlo per fare le cose come più aggradano. Inoltre già dalla versione 2.2, Samba supporta dierenti sistemi di autenticazione e salvataggio dei dati degli utenti. Si possono mantenere gli account degli utenti sul classico le smbpasswd, o sul più modermo ldap o tdbsam. Non dimentichiamo inoltre winbind un demone che permette di utilizzare sulla macchina *nix gli utenti impostati su di un dominio NT.

Prestazioni Le attuali versioni di Samba sono un ottimo sostituto per un server Windows che fornisce condivisione di le e stampanti. Come di- mostrano i test comaparativi tra Samba e Windows 2000 server eettuati da PCmag [8]e Hp [7]. Il test è stato eetuato su 3 diversi diversi tipi di hardware:

fascia bassa Micron ClientPro XLU Pentium II/233 128MB Ram fascia media Dell Dimension XPS T550 550 Mhz PIII 256 MB Ram fascia alta Dell Dimension 4100, 1Ghz p3 512 Mb Ram

Tutte le macchine erano equipaggiate con HardDisk Ide e schede rete 3Com 3C905C. Per i test è stata utilizzata la suite di test Netbench 7.02, conguran- do 30 client per generare suciente traco di rete. Su entrambe le macchine Windows e Linux sono stati eliminati i servizi non necessari (server web serve ftp) inoltre sulla macchina Linux è stato ricompilato il kernel per eliminare i moduli non necessari. Sui due tipi di sistema non sono state eseguite parti- colari ottimizzazioni benchè entrambi possiedano di default impostazioni che permettono una buona gestione del cahing dei le. Anche causa del compor- tamento più aggressivo di Samba per quanto riguarda il caching dei le si può notare come nel graco del tempo medio di risposta (gura 1.2) a parità di hardware ora prestazioni migliori del concorrente. Nell'altro graco (gura 1.1) possiamo notare che servendo pochi client Samba e Windows presentino valori di throughput praticamente uguali mentre al crescere del numero di Host samba fornisce prestazioni migliori.

6

Se un server non risponde più alle richieste, può essere rimpiazzato da un altro che ne

acquisisce l'Ip, il tutto in maniera trasparente rispetto agli altri servizi di rete.

Figura 1.1: Troughput

Figura 1.2: Response time

In questo paragrafo verrà analizzato il funzionamento di una generica ses- sione Samba e verranno introdotti alcuni concetti fondamentali di Windows Networking utili a comprendere il funzionamento della sessione stessa.

1.3.1 Concetti di Windows Networking

Nella sua forma più semplice il sitema di Windows Naming è basato su un modello di tipo broadcast. Un sistema che vuole partecipare ad una network Windows dionde il suo nome Netbios a tutti gli altri host della subnet in cui è inserito. Se nessun altro sistema si oppone il nome è associato alla macchina e si può procedere al suo utilizzo.

Per identicare un sistema dal nome, il nome richiesto è mandato in broadcast per tutta la rete e il sistema che possiede il nome è l'unico a rispondere.

Samba è in grado di fornire e partecipare a questi servizi sia per quanto riguarda registrazione del nome sulla rete che per la ricerca di altri nomi.

NetBios Name Service è fornito dal componente nmbd, che permette ad una

*nix box di registrare il suo nome ed essere riconosciuta dai sistemi Windows.

La suite Samba include anche l'utility nmblookup che ha funzionalità simili a quelle che nslookup ore per il Domain Naming Service. Grazie a questo compontente si può ricavare l'indirizzo associato ad un nome netbios.

Ogni sistema Windows può avere più di un nome Netbios associato. Un nome identica l'host, un'altro nome può essere associato all'utente loggato sul sitema.

Il sistema di registrazione dei nomi tramite broadcast funziona su reti piccole e su una singola subnet, ma genera molto traco e non è scalabile.

Il browsing di una rete permette ad un utente di vedere i nomi degli host sulla rete. Per fare ciò, l'host in questione deve aver ricevuto e memorizzato tutte le corrispondenze dei nomi della rete e host connessi.

Per questo motivo sono stati classicati gli host in master browser e name server. Per supportare il browsing della rete si usano i master browser, che mantengono in cache le informazioni di broadcast degli altri sistemi. Quando un sistema vuole visitare le Risorse di rete non fa altro che interrogare il master browser, senza generare traco superuo. Il master browser è scelto tramite un processo di elezione. Se il master browser è riavviato o risulta non disponibile, si ha un elezione tra le workstation rimanenti per il ruolo di master browser. Samba può essere usato come master browser in una sessione di Windows networking, puo essere congurato sia per forzare una elezione di un browser sia per partecipare ad essa.

L'utilizzo di un master browser dipende dall'archittetura della rete infatti

è noto che il broadcast non funziona attraverso router e subnet dierenti.

Per funzionare attraverso router, il servizio di name service ha bisogno di un name server dedicato detto WINS.

Il Windows Internet Naming Service (WINS) [11] serve a trasformare i nomi dei computer in indirizzi IP per l'instradamento e la consegna dei pacchetti. WINS è studiato per arontare il problema dell'individuazione di risorse di rete in ambiente TCP/IP attraverso la congurazione e il man- tenimento automatici delle tabelle di mappatura dei nomi NetBIOS e degli indirizzi IP, svolgendo insieme funzioni elementari come impedire la dupli- cazione di nomi in rete. WINS è un servizio complemetntare per il DHCP e possiede una strumentazione completa e centralizzata per l'amministrazione e la congurazione di server WINS, tabelle nomi statiche e informazioni di duplicazione.

Anche se nella rete è attivo un servizio Wins, i client continuerano a interrogare il master browser. Quest'ultimo si rivolgerà al server Wins per la risoluzione dei nomi, ripsondendo alle richieste dei client.

Samba può quindi essere impostato per usare un Wins server pre-esistente, può essere integrato in una rete Microsoft come una normale workstation, senza assolvere funzioni speciali. Samba alternativamente può anche fun- zionare in sostituzione di un server Wins, tutti i vantaggi descritti per l'af-

dabilità di GNU/Linux come master browser valgono anche se si utilizza come server wins.

1.3.2 File sharing & print sharing

La maggior parte dei modelli di le sharing che sono oerti nei sistemi Win- dows sono disponibili con Samba. Grazie al supporto di linux per le home directory, queste utlime possono essere esportate e accessibili dai client Win- dows, gli utenti che si loggano al sistema hanno accesso alla loro directo- ry privata. Le condivisioni di Windows hanno principalmente due tipi di controllo di accesso:

• livello condivisione: a ogni disco, cartella, le o stampante condivisa viene assegnata una password

• livello utente: ad ogni risorsa condivisa si può assegnare un elenco di utenti che vi possono accedere

Samba supporta entrambi i tipi di controllo di accesso, l'utente non nota quindi nessuna dierenza rispetto a un server Windows e non necessita di alcun software aggiuntivo da installare sui client.

Samba ore inoltre l'abilità di memorizzare i proli degli utenti all'interno

delle condivisioni, grazie a ciò un utente può cambiare workstation e avere

con lui le stesse impostazioni e preferenze (desktop, menu, ecc.).

Oltre che alla condivisione di le Samba, può essere usato per la condivisione delle risorse di stampa. Samba fornisce quindi l'accesso alle macchine Win- dows delle stampanti Unix. Alcuni sistemi Windows devono inoltre essere in grado di scaricare i driver di stampa dal server che condivide la stampante.

Tutto ciò può essere fatto senza lavoro aggiuntivo dell'utente ma con un piccolo setup iniziale. Se il sistema di stampa *niX è aggiunto ad alcuni pac- chetti di stampa postscript (come Ghostscript) allora è possibile per i sistemi Windows usufruire di servizi che altrimenti non avrebbero a disposizione.

Per gli utenti unix che vogliono stampare su macchine Windows è a disposizione l'utility smbprint, questa può essere chiamata dall'utente o usata come ltro.

Cenni sulla stampa Windows

Windows in origine fu sviluppato per un utilizzo da parte di un singolo utente, ciò signica che per prima venne sviluppata una printig API (Apli- cation Program Interface) locale. Sucessivamente venne progrettato un pro- tocollo per fornire un sistema di stampa remoto tramite la API locale. In- dubbiamente la stampa Windows è molto più semplice da usare per utenti e programmatori ma presenta alcuni problemi.

Ci sono pricipalmente quattro diversi modi per stampare in Windows:

1. Printing spooling path;

2. Win 3.X printing system;

3. Win 9X point-and-print path (RAP calls);

4. Windows NT/2000/XP printign system (DCE/RPC ).

Printing spooling path Questo è il sistema di stampa in origine utiliz- zado dal DOS, il cui meccanismo consiste nell'aprire una periferica (LPT ad esempio) e inviare al suo interno dei dati. Questo sistema di stampa può essere utilizzato da remoto tramite SMBsplopen, fornendo però solo un rudimentale supporto per il monitoraggio della coda di stampa. Tramite il printing spooling path non è introdotto il concetto di driver nel sistema operativo, ciascun applicativo utilizza un driver a se stante per l'uso della periferica.

Windows 3.x printing system Windows 3.x è stata la prima versione di

Windows ad avere incorporato il concetto di driver indipendenti dall'appli-

cazione. Questi driver devono essere installati su ciascun client (il concetto

di client che scarica automaticamente i driver fu introdotto con win9x), og- gigiorno la creazione delle virtual printer (code di stampa) tramite API è alla base delle applicazioni Windows.

Windows 9x printing system Windows 9x ha la capacità di scaricare au- tomaticamente al momento del setup i le del driver per una stampante colle- gata. I client Windows 9x usano le chiamate RPC (Remote Procedure Call) per ottenere le informazioni sul driver da scaricare, questo include il percor- so da cui prelevare i driver, e le informazioni sulla stampante (nome, col- locazione,commenti ecc). Rispetto all'implementazionde delle printing API di Windows 3.1 sono state aggiunte nuove funzionalità che consentono un maggiore controllo delle code di stampa (come pausa, cancellazione, pulizia coda di stampa).

Windows NT/2000/XP printing system Windows NT/2000/XP han- no un metodo di stampa completamente dierente, dalle precedenti versioni.

• delle chiamate SMB aprono la connessione alla condivisione \\SPOOLSS creando una pipe;

• delle chiamate DCE/RPC sono eettuate alla pipe SPOOLSS per aprire la connessione alla stampante, creare nuova stampante, aggiungerne i driver.

Tramite questa implementazione tutto ciò che può essere fatto localmente utilizzando le chiamate alle Printing API, può essere eseguito da remoto. Il tallone di achille di questa struttura è il sistema di spooling (notoriamente instabile) al quale arrivano le chiamate delle API[15].

Tutte le comunicazioni di stampa eettuate usando DCE/RPC funzio- nano tramite protocollo SMB e seguono il seguente schema:

1. un Print Job è inviato nella coda di stampa;

2. dei dati vengono inseriti nel Job;

3. viene avviato il lavoro di stampa.

Implementazione della stampa Windows in Samba

Per essere competitivo con l'ambiente Windows sul piano della stampa, Sam- ba deve implementare tutti e quattro i sistemi sopra elencati. Ecco elencate alcune della maggiori dicoltà nell'implementazione di questa struttura.

• l'impelementazione DCE/RPC è terribilmente complessa;

dati formattati non correttamente oppure dati inattesi, va irrimedia- bilmente in crash;

• in Win NT4.x i driver venivano utilizzati in Kernel mode, in Windows 2000 vengono utilizzati in User Mode;

• non c'è protezione dalle race condition, ossia se due amministratori installano dei driver contemporaneamente ciascuno può fare danno all'altro.

Per far fronte alle problematiche sopra esposte, venne creata una sezione dedicata nel progetto Samba chiamata Samba Printer Code la quale ore alcune caratteristiche molto interessanti:

• fornisce la possibilità di download dei driver;

• fornisce possibilità di immagazzinamento remoto per dati di stampa;

• consente il mapping tra le stampanti Windows le code di stampa Unix.

Samba Printer Code utilizza un database interno tdb (technical database) per la memorizzazione delle informazione quali ad esmpio la capacità della stampante. Conseguentemente ad ogni arrivo di job nella coda di stampa una nuova entry è aggiunta nel database. Il passo sucessivo del processo di stampa consiste nel memorizzare i dai all'interno di un le temporaneo. Per rilevare lo stato della stampante le macchine Windows eseguono il polling, se venisse creata un istanza di lpq sulla macchina unix per ogni richies- ta si otterrebbe una notevole diminuzione delle prestazioni. Memorizzando nel database tdb le informazioni sull'ultimo stato della coda si può evitare l'esecuzione di numerosi lpq sostituendoli con interrogazioni alla base dati.

Purtroppo allo stato attuale dello sviluppo solo CUPS implementa ap- pieno le chiamate API, gli altri si limitano a nascondere sotto le interfacce i classici strumenti (lpq, lprm, lpc).

Per concludere la trattazione della stampa tramite Samba ecco alcuni dei principali obiettivi che gli sviluppatori si sono posti:

• migliorare e arricchire le Unix printig API;

• migliorare i driver per le stampanti inkjet, (le stampanti con emulazione postscript sono supportate abbastanza bene).

1.4 Analisi pacchetti

In questo paragrafo verranno analizzate le principali caratteristiche dei pro-

tocolli Smb, Netbios e Tcp/Ip e la loro collocazione all'interno dello stack

Figura 1.3: stack tcp e posizione protocollo smb

del modello protocollare TCP/IP (g1.3)sui quali si basa il funzionamento di Samba.

1.4.1 Netbios e Netbeui

I protocolli NetBIOS ed NetBEUI [13] sono stati sviluppati rispettivamente nel 1983, dalla Sytek per IBM, e nel 1985 da IBM stessa. Ancora oggi restano molto diusi nei sistemi Microsoft, in virtù dei loro pregi nell'ambito delle reti locali.

Con l'introduzione di Token Ring, IBM nel 1985 denì delle estensioni a NetBios (NetBIOS Extended User Interface NetBEUI) che permettevano di appoggiarsi ad un data-link 802.2 (Token Ring o Ethernet). Microsoft ha in- iziato ad usare NetBEUI come protocollo di rete su Windows for Workgroup (Windows 3.1) e poi su tutte le versioni successive ma, al contempo, con la diusione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche su IPX e IP, oltre che su altri protocolli.

All'epoca, l'obiettivo era infatti quello di creare un protocollo su misura per le LAN di dimensioni contenute (no a circa 200 nodi), quindi doveva essere piccolo, semplice, veloce e doveva permettere di assegnare nomi umani alle risorse, invece dei complessi indirizzi usati dal TCP/IP. Inoltre NetBIOS è stato progettato perchè usasse intensamente i broadcast (messaggi uno a tutti), piuttosto che interrogare un'entità centralizzata.

In questa logica, un computer che in seguito all'accensione voglia regis-

trarsi con il proprio nome NetBIOS come nuovo nodo, deve inviare appositi

messaggi broadcast per farsi accettare come nuovo nodo attivo. Se il nome è

già usato, il precedente possessore di quel nome deve inviare un messaggio di

risposta per respingere la scelta. Se invece un computer vuole localizzare un

nodo preesistente, invierà ancora altri broadcast nel tentativo di contattare

quello specico nodo. Il computer remoto è sempre tenuto a rispondere ai

computer potranno comunicare senza usare broadcast.

Per essere più precisi, l'implementazione del NetBEUI nei sistemi Mi- crosoft dierisce dalle ultime versioni del NetBEUI standard (NetBEUI 3.0) per alcuni aspetti, pur preservandone la compatibilità. Ad esempio, il Net- BEUI di Microsoft, chiamato NBF (NetBIOS Frame), presenta alcune miglior- ie rispetto al protocollo standard, ed invece di interfacciarsi con i livelli supe- riori tramite il consueto NetBIOS, utilizza un'altra interfaccia più essibile, chiamata TDI, Transport Driver Interface, cioè interfaccia del dispositivo di trasporto.

I nomi usati da NetBIOS sono fatti di 16 caratteri alfanumerici e possono essere di due tipi:

• nomi unici: possono essere usati per identicare al più una sola risorsa in rete

• nomi di gruppo: che invece si associano a più nomi unici

In ambiente Windows, un nome unico può individuare un computer della rete, un utente loggato su un sistema della rete, sia anche un servizio oerto da un computer (una certa applicazione o una funzionalità particolare).

Dato che NetBIOS non dispone dei numeri di porte, come quelle del TCP/IP, per poter identicare queste funzionalità viene riservato il sedicesimo carat- tere, che diventa un susso e quindi limita il nome a soli 15 caratteri. Le comunicazioni sono di tre tipi: sessioni, datagrammi, broadcast. Le sessioni si usano per scambiare con un altro nodo rilevanti quantità di dati con rile- vamento e correzione d'errore. I datagrammi per inviare ad uno o più nodi (quando il destinatario è un gruppo) messaggi di dimensioni modeste ma senza dover stabilire una sessione. I broadcast inne, si usano per comuni- care messaggi di dimensioni modeste a tutti i nodi in ascolto. In sessione è possibile inviare no a 64 Kbyte di dati per messaggio. Con i datagrammi si è limitati a 512 byte per messaggio ed inoltre non si ha la garanzia che i dati arrivino. Tuttavia, negli ambiti in cui queste limitazioni non costituis- cono un problema insormontabile, lavorare con i datagrammi rimane molto semplice e veloce.

Per distinguere il traco in una stessa rete è stata sviluppata un'apposita funzionalità, chiamata NetBIOS Scope ID. Si tratta di una stringa di carat- teri aggiunta alla ne del nome. Due computer devono avere lo stesso scope ID per comunicare.

I limiti di Netbios over Netbeui La diusione di Internet ha messo

subito in luce quali sono i limiti di NetBIOS e del suo supporto NetBEUI

quando la rete cresce di dimensioni. Tralasciando problemi seri ma non

insormontabili, come il degrado prestazionale sulle WAN legato all'uso dei

broadcast, rimangono tuttavia altri problemi di non facile soluzione: innanz- itutto l'unicità nomi. Dato che due computer non possono usare due nomi uguali nella stessa rete, bisognerebbe trovare un nome diverso per ogni com- puter connesso, cosa non banale in una rete geograca. In secondo luogo, a causa dela non gerarchicità dei nomi, NetBEUI non permette il routing.

Cioè, dato un nome NetBIOS, è impossibile sapere quale sia la strada per raggiungerlo. Il problema in questo caso risiede nel fatto che i nomi NetBIOS non contengono alcuna informazione gerarchica. In principio infatti il Net- BIOS fu pensato per reti semplici e non strutturate a dierenza di TCP/IP.

Quando la rete diventa Internet, è immediato rendersi conto che un indi- rizzo IP sia molto più comodo e molto più versatile di un nome normale.

Un ultimo problema, forse il più importante, è che i router di Internet non permettono il propagarsi dei broadcast, utili al protocollo NetBIOS quando cerca di localizzare un nodo.

Per evitare che il NetBIOS aondasse, tornò molto comodo a Microsoft il fatto di poter abbinare l'interfaccia NetBIOS ad un protocollo molto più

essibile del NetBEUI, come il TCP/IP, e limitando l'impiego del NetBEUI nell'ambito delle reti locali tra sistemi Microsoft. In questo modo ogni mes- saggio elaborato da NetBIOS viene incapsulato in un messaggio TCP/IP, che non sore delle limitazioni di cui parlavamo prima. Chiaramente sor- gono nuove complicazioni in seguito alle quali si ebbe la creazione dei servizi WINS (derivante dal servizio DNS diuso in Internet) e la creazione del le LMHOSTS (derivante da HOSTS)

.

Netbios over Tcp/Ip Per rendere possibile l'interfacciamento tra Net- BIOS e TCP/IP è necessario che NetBIOS usi i nomi di host, mentre TCP/IP deve usare indirizzi. Ecco che nasce il NetBIOS over TCP/IP, chiamato anche NBT, descritto negli RFC 1001 e 1002 [14]. Esso è in grado di lavorare su reti geograche, basandosi su associazioni tra nomi NetBIOS e indirizzi IP fornitegli dall'esterno.

Iniziamo col dire che i nodi, detti NBT, possono operare seguendo quattro modalità standard:

b-nodi (nodi broadcast) usano broadcast sia per la registrazione che per la risoluzione dei nomi in indirizzi IP. I b-nodi sorono ancora del problema dei broadcast di NetBIOS: se i nodi sono separati da router, non riusciranno a contattarsi.

p-nodi (nodi punto-punto) scoprono l'IP della risorse interrogando con richieste unicast un server WINS noto. WINS, (Windows Internet

7

Host File: le locale memorizzato nel computer con sitema operativo Windows utiliz- zato per tradurre il nome di dominio in indirizzo IP

LmHost File: un le locale memorizzato nel computer con sitema operativo Windows

utilizzato per il nome NetBIOS in indirzzo IP

tando i server DNS, fornisce una lista di coppie nome NetBIOS indi- rizzoIP.

m-nodi (nodi misti) usano prima il broadcast come i b-nodi e poi le richi- este come i p-nodi.

h-nodi (nodi ibridi) l'opposto degli m-nodi, cioè prima contattano un serv- er WINS noto, poi, se la richiesta ha esito negativo, utilizzano il broadcast.

Una volta ricavati gli indirizzi IP corrispondenti ai nomi netbios, si pos- sono aggirare i limiti descritti in precedenza ed è così possibile contattare i nodi remoti.

I client Microsoft usano un sistema leggermente più complicato. Con- sultano in ordine: una cache interna, il server WINS se presente, poi fan- no broadcast, e per nire leggono il le LMHOSTS. LMHOSTS è simile al

le HOSTS delle macchine UNIX e WINDOWS. Torna utile se non non si dispone di nessun server WINS e non si riesce a risolvere un nome remoto tramite broadcast perchè il nodo è al di la di uno o più router. In realtà LMHOSTS può tornare utile anche se il destinatario risiede nella stessa rete locale. Infatti, per non essere obbligati a subire un'eccesso di broadcast sulla propria rete, è possibile precaricare le associazioni del le LMHOSTS più usate nella cache. Nel protocollo TCP/IP, per stabilire una comuni- cazione, è necessario denire le porte a cui inviare le richieste. NBT usa prevalentemente le seguenti porte:

• 137: risoluzione dei nomi NetBIOS (UDP)

• 138, 139: datagrammi (UDP)

• 139: sessioni

1.4.2 Autenticazione

I due principali problemi di sicurezza nella condivisione le sono autenti- cazione (determinare chi richiede servizio) e autorizzazione (determinare cosa puoò fare chi richiede servizio). I sistemi nix supportano vari tipi di autenti- cazione (login password, kerberos). Anche Windows ha un sistema di login, che puo essere di tipo locale, oppure login ad un dominio. Samba crea dier- enti tipi di integrazione tra i sistemi Windows e i sitemi Unix, per esempio Samba può usare un PDC per l'autenticazione oppure può fornire un auten- ticazione locale o ancora funzionare lui stesso da PDC per servire l'itera rete Windows.

A causa della dierenza dei sistemi di criptazione tra Windows e Unix

non è possibile convertire un sistema di autenticazione in un altro, per

Figura 1.4: Schermata principale ethereal

questo motivo Samba fornisce un meccanismo per mantanere i due livelli di autenticazione separati.

A causa della varità di sistemi di autenticazione delle macchine nix questa funzionalità richiede un sforzo di setup iniziale, ma consente di ottenere un vantaggio nell'eliminazione delle richieste di username e password agli utenti e elimina la confusione di dover mantenere password diverse in ambienti diversi.

Grazie all'utility rpcclient gli utenti possono cambiare la loro password o interrogare il database delle informazioni nei server Microsoft.

1.4.3 Dettaglio pacchetti

In questo paragrafo verranno dettagliati alcuni esempi di comunicazione tramite protocollo SMB. Per ottenere la cattura dei pacchetti è stato uti- lizzato il programma Ethereal [12] che è stato installato sulla macchina contenente anche il le server Samba. Sulla rete locale erano presenti so- lo le macchine che hanno partecipato all'esperimento e sono stati disattivati eventuali servizi che avrebbero potuto compromettere la riuscita ottimale della prova (es: dhpc, ntpd). La cattura delle immagini è avvenuta in due momenti:

Cattura dei pacchetti in real time: durante questa fase è stato avviato

il programma (con privilegi di root)e sono stati impostati alcuni parametri

di congurazione che si possono ossevare in g (1.4)(Capture Package in

Figura 1.5: Composizione della rete: server Samba, client Windows XP

promiscuous mode, Update list of packets in real time, Automatic scrolling in live capture, Enable MAC name resolution, Enable network name resolu- tion, Enable transport name resolution). Dopo questi settaggi si è iniziata la cattura delle immagini selezionando start capture dal menu del program- ma. Cessata la cattura dei pacchetti sono state analizzati i dati ottenuti mediante salvataggio di le in un formato compatibile con ethereal. La rete utilizzata per l'analisi dello scambio dei pacchetti è descritta dalla g 1.5, nella quale sono presenti un le server Samba (indirizzo ip 192.168.1.20) e un client Windows XP (192.168.1.22).

Dopo l'accensione del client Windows avviene l'avviso tramite broadcast (destinazione 192.168.1.255) a tutta subnet della volontà di registare il nome netbios PCXP all'interno del gruppo di lavoro WORKGROUP. Per indi- viduare la dierenza tra nome della macchina e nome del gruppo di lavoro bisogna analizzare i ag del pacchetto nel dettaglio. Per i nomi host è attivo il ag unique, mentre per i nomi del workgroup è attivo il ag group come si può notare in gura 1.6.

Nel frame n 16 illustato in g 1.7 avviene l'annuncio dell'avvenuta regis- trazione dell'host (Host Announcement) nel quale viene indicata anche la tipologia di sitema operativo (NT Workstation).

Prima di procedere nella descrizione del funzionamento del processo di elezione del master browser è necessario descriverne il funzionamento nel dettaglio.

Esistono varie possibilità di partecipazione al processo elettivo ,princi- palmente come:

Master Browser mantiene la lista principale di tutti i computers e delle

shares della rete. Tutti i Workgroup o i Domini hanno un master

browser;

Figura 1.6: ag unique e ag group

Domain Master Browser il master browser per un dominio. Il PDC del dominio vince sempre le elezioni per il master Browser;

Subnet Browser or Local Master Browser lavora su una subnet for- nendo la lista delle risorse ai client e mantendo in costante aggior- namento il domain master browser. generealmente questo ruolo è attribuito al BDC;

Backup Browser Il domain master browser manda periodicamente una copia della lista delle risorse al backup browser nel caso di failure del master;

Potential browser Un computer che può diventare un master o backup browser;

Non-Browser Un computer che non diventerà mai master o backup brows- er.

Siccome in una rete le macchine possono essere connesse e sconnesse in ogni momento, il master browser locale aggiorna continuamente la lista e la invia alle macchine che ne fanno richiesta. Il master browser di dominio invece raccoglie le liste di ogni sottorete e le mette a disposizione dei master browser locali.

Un elaboratore diventa master browser locale a seguito di una elezione

che può essere eettuata in qualunque momento (ad esempio quando un

1 0.000000 QuantaCo_2e:6d:f5 Broadcast ARP Who has 192.168.1.22? Gratuitous ARP

4 3.332689 192.168.1.22 192.168.1.255 NBNS Registration NB PCXP<00>

8 6.329191 192.168.1.22 192.168.1.255 NBNS Registration NB WORKGROUP<00>

12 9.510076 192.168.1.22 192.168.1.255 NBNS Registration NB PCXP<20>

16 12.543572 192.168.1.22 192.168.1.255 BROWSER Host Announcement PCXP,

Workstation, Server, NT Workstation

17 20.737183 192.168.1.22 192.168.1.255 NBNS Registration NB WORKGROUP<1e>

21 23.735674 192.168.1.22 192.168.1.255 BROWSER Request Announcement PCXP

22 23.735809 192.168.1.22 192.168.1.255 BROWSER Host Announcement PCXP,

Workstation, Server, NT Workstation, Potential Browser 23 25.236801 192.168.1.22 192.168.1.255

BROWSER Request Announcement PCXP

Figura 1.7: Samba pacchetti 1-23

[global]

...

local master = yes os level = 34

preferred master = yes ...

Figura 1.8: smb.conf: Samba congurato come Preferred Master nuovo elaboratore si presenta in rete). Riguardo a tale elezione Microsoft assegna ai suoi sistemi operativi un valore, detto livello, che cresce sempre di più per i sistemi operativi più recenti (ad esempio una macchina con MS- Windows 98 ha livello 2, una con MS-Windows NT 4 Workstation ha livello 17, una con MS-Windows NT 4-Server ha livello 32, una con MS-Windows 2000-Server ha livello 64).

L'elezione avviene sulla base di questo valore, in caso di parità viene esaminata la funzione svolta dalla macchina (si ricordi che un PDC diviene sempre anche Domain Master Browser) in caso di ulteriore parità viene scelta la macchina che è da più tempo in rete.

Con Samba il livello per la partecipazione all'elezione può essere scelto in sede di congurazione. Nell'esempio seguente vengono mostrate le direttive da inserire nella sezione [global] del le smb.conf anché il server Samba sia master browser locale prevalendo su macchine MS-Windows no aalla ver- sione NT-server: Dopo l'avvio del computer si può notare come esso annunci se stesso in rete e le sue caratteristiche per partecipare (ed eventualmente vincere)l'elezione del ruolo di master browser (frame 26 e 28).

Nei pacchetti 26 e 28 illustati in g 1.9il pc WINXP invia una richiesta in broadcast nella subnet per l'avvio del processo elettivo.

Come si può osservare nel dettaglio del pacchetto n 34 (g 1.10) serversmb risponde alle query sul processo elettivo. Da notare in particolare come il server Samba con la congurazione precedente si presenti in rete come un Browse server in standby identicato come Windows NT Workstation.

Nel dettaglio del pacchetto 38 (g 1.11)si può notare come il serversmb abbia vinto l'elezione del ruolo di master browser e contemporaneamente di Backup Browser.

Nel pacchetto 50 (g 1.12 ) vi è l'annuncio uciale del serversmb come masterbrowser per il gruppo di lavoro WORKGROUP. Nel numero 53 si può notare come il PC xp abbia assunto il ruolo di potential browser, risulta plausibile pensare che diventerà master browser in caso di failure del server serversmb.

Nei pacchetti dal 68 al 72 (visibili in g 1.13) si instaura la connessione

vera e propria (lo si intuisce anche dall' utilizzo del protocollo SMB). Prima

dell'avvio della connessione vera e propria si nota il meccanimo del three way

26 29.743473 192.168.1.22 192.168.1.255 BROWSER Browser Election Request

28 31.744965 192.168.1.20 192.168.1.255 BROWSER Browser Election Request

30 33.744758 192.168.1.20 192.168.1.255 NBNS Name query NB WORKGROUP<1d>

31 35.744325 192.168.1.20 192.168.1.255 BROWSER Browser Election Request

32 35.744439 192.168.1.20 192.168.1.255 NBNS Name query NB WORKGROUP<1d>

33 35.744569 192.168.1.20 192.168.1.255 NBNS Name query NB WORKGROUP<1d>

Figura 1.9: Samba: Pacchetti 26-33

Source IP: 192.168.1.20 Source Port: 138

Microsoft Windows Browser Protocol

Command: Browser Election Request (0x08) Election Version: 1

Election Criteria: 0x14010f02 Election Desire: 0x02

.... ...0 = Backup: NOT Backup Browse Server .... ..1. = Standby: Standby Browse Server .... .0.. = Master: NOT Master Browser

.... 0... = Domain Master: NOT Domain Master Browse Server ..0. .... = WINS: NOT WINS Client

0... .... = NT: NOT Windows NT Advanced Server Browser Protocol Major Version: 15

Browser Protocol Minor Version: 1 Election OS: 0x14

.... ...0 = WfW: Not Windows for Workgroups

...1 .... = NT Workstation: Windows NT Workstation ..0. .... = NT Server: Not Windows NT Server

Figura 1.10: Pacchetto 34: dettaglio

Source IP: 192.168.1.20 Source Port: 138

Microsoft Windows Browser Protocol

Command: Browser Election Request (0x08) Election Version: 1

Election Criteria: 0x14010f07 Election Desire: 0x07

.... ...1 = Backup: Backup Browse Server .... ..1. = Standby: Standby Browse Server .... .1.. = Master: Master Browser

.... 0... = Domain Master: NOT Domain Master Browse Server ..0. .... = WINS: NOT WINS Client

0... .... = NT: NOT Windows NT Advanced Server Browser Protocol Major Version: 15

Browser Protocol Minor Version: 1 Election OS: 0x14

.... ...0 = WfW: Not Windows for Workgroups

...1 .... = NT Workstation: Windows NT Workstation ..0. .... = NT Server: Not Windows NT Server

Figura 1.11: Samba: dettaglio Pacchetto 38

handshaking nei pacchetti TCP. Nel pacchetto 70 vi è l'avvio della richiesta di connessione al server SMB (NBSS Netbios Session Service)

1.5 Esempio di congurazione di Samba

In questo paragrafo verrà descritta la congurazione di Samba utilizzando com esempio la descrizione di un le di congurazione. La congurazione di Samba (i demoni smbd e nmbd) viene gestita dal le smb.conf, un normale

le di testo ASCII con queste caratteristiche di massima:

• I parametri di congurazione vengono forniti nella forma opzione = valore Il le viene diviso in più sezioni delimitate da un nome tra parentesi quadre che deniscono una share (condivisione), oltre alla sezione generale [global];

• Le righe di commento sono precedute da # o ;;

• I paramteri di congurazione possono estendersi su più righe di smb.conf utilizzando una backslash a ne riga;

• Le opzioni e i valori sono case insensitive, ma se si indica un path nel

le system questo è case sensitive;

45 45.743928 192.168.1.20 192.168.1.255 NBNS Registration NB WORKGROUP<1d>

47 47.743472 192.168.1.20 192.168.1.255 BROWSER Browser Election Request

48 47.743611 192.168.1.20 192.168.1.255 NBNS Registration NB WORKGROUP<1d>

49 47.743765 192.168.1.20 192.168.1.255 BROWSER Request Announcement

50 47.744337 192.168.1.20 192.168.1.255 BROWSER Local Master Announcement SERVERSMB,

Workstation, Server, Print Queue Server, Xenix Server, NT Workstation, NT Server, Master Browser

51 47.744440 192.168.1.20 192.168.1.255 BROWSER Domain/Workgroup Announcement WORKGROUP, NT Workstation, Domain Enum

52 49.744459 192.168.1.20 192.168.1.255 BROWSER Browser Election Request

53 56.903549 192.168.1.22 192.168.1.255 BROWSER Host Announcement PCXP, Workstation, Server, NT Workstation, Potential Browser

Figura 1.12: Samba: Pacchetti 45 - 53

68 135.220158 192.168.1.22 192.168.1.20

TCP 1056 > netbios-ssn [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 69 135.220195 192.168.1.20 192.168.1.22

TCP netbios-ssn > 1056 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 70 135.220322 192.168.1.22 192.168.1.20

NBSS Session request, to SERVERSMB<20> from ACER-UV59QVXL7X<00>

71 135.220359 192.168.1.20 192.168.1.22

TCP netbios-ssn > 1056 [ACK] Seq=1 Ack=73 Win=5840 Len=0 72 135.223206 192.168.1.20 192.168.1.22

NBSS Positive session response

Figura 1.13: Pacchetti 68 - 72

• Per separare una serie di valori possono essere usati sia virgole che spazi vuoti;

• Possono essere utilizzate delle variabili, precedute dal simbolo percento all'interno dei valori (es: path = /home/%u);

• Si può includere a smb.conf un altro le di congurazione con l'opzione include (es: include = /etc/samba/smb.conf.%a).

Le opzioni di congurazione possono essere di due tipi fondamentali:

• global appaiono solo nella sezione [global] e deniscono i comporta- mente generali del server Samba

• share appaiono all'interno di speciche share e deniscono il com- portamento riguardo alla specica share. Se appaiono in [global]

deniscono i comportamenti di default per ogni share.

Qualsiasi opzione deve essere inclusa in una sezione. Esistono le tre sezioni speciali:

1. [global] Sempre presente, di solito ad inizio le, denisce le opzioni di default valide per tutte le condivisioni (possono essere sovrascritte da opzioni presenti nelle speciche sezioni) e i parametri generali di congurazione del server

2. [printers] E' una sezione speciale utilizzata per condividere l'accesso via rete a delle stampanti

3. [homes] E' una sezione speciale che coincide con la home directory di un utente autenticato. Di fatto è una condivisione generica con il nome dell'utente che accede a Samba

Oltre a queste sezioni speciali ne possono esistere altre, il nome di ogni sezione coincide con il nome della relativa condivisione, così come appare al client SMB. In gura 1.14 è illustrato un semplice esempio del principale

le di congurazione di Samba smb.conf . La distribuzione utilizzata per l'esempio è Fedora core 2.

Di seguito una breve spiegazione della congurazione della suite Samba relativa al sopracitato smb.conf:

workgroup nome netbios del gruppo di lavoro

server string nome netbios del pc su cui è installato Samba

encrypt passwords indica a Samba di utilizzare password criptate indis-

pensabile per l'utilizzo con win 98 e sucessivi

# Global parameters [global]

workgroup = WORKGROUP server string = serversmb encrypt passwords = Yes security = user

passwd program = /usr/bin/passwd %u

passwd chat = *New*password* %n\n *Retype*new*password* %n\n \

*passwd:*all*authentication*tokens*updated*successfully*

unix password sync = Yes

log file = /var/log/samba/%m.log max log size = 50

wins support = Yes [homes]

comment = Home Directories read only = No

create mask = 0600 directory mask = 0700 browseable = No

#sezioni il cui nome coincide con la condivisione [public]

comment = public path = /public read only = No browseable = Yes create mask = 0777 directory mask = 0777

Figura 1.14: smb.conf: esempio

passwd program & chat programmi utilizzati per permettere agli utenti Windows di cambiare le loro password dai client.

unix password sync Mantiene sincronismo tra le password unix e le pass- word Windows.

log le & max log size indicano la posizione e la dimensione massima dei

le di log di Samba

wins support tramite questo parametro Samba viene utilizzato per la risoluzione dei nomi wins.

L'impostazione del parametro security merita una descrizione più appro- fondita. Le seguenti opzioni sono disponibili:

security = share Si ha il controllo di accesso a livello di condivisione:

il client che vuole accedere a una risorsa invia ogni volta una paro- la d'ordine e nessun nominativo-utente. Samba tenta di dedurre il nominativo-utente dalla direttiva valid users eventualmente inserita nella sezione di condivisione di quella risorsa (come illustrato in segui- to), oppure dal nome dell'elaboratore cliente, o, in caso di insuccesso, da quanto indicato con il parametro guest account (questo solo se fra i parametri di condivisione è indicato guest ok = yes e guest only = yes).

Questo livello di sicurezza si usa, soprattutto nel caso di utenti MS- Windows e GNU/Linux non coincidenti, per condividere porzioni di

le system quando si ha interesse a far sì che tutti gli utenti abbiano gli stessi diritti sui le condivisi (con l'impostazione guest account = utentesmb il proprietario delle risorse condivise sarà sempre l'utente GNU/Linux utentesmb qualunque sia il nominativo dell'utente MS- Windows che si connette).

security = user Con questa impostazione, che è quella predenita, si ha il controllo di accesso a livello di utente: il client che vuole accedere a una risorsa invia al momento della connessione una coppia utente- parola d'ordine in base alla quale avviene l'autenticazione da parte del servente. Se la connessione viene accettata il cliente può accedere a tutte le risorse condivise senza doversi autenticare nuovamente a ogni accesso.

Il controllo delle utenze viene eettuato dal server Samba in base al con-

tenuto del le dei suoi utenti che solitamente è smbpasswd. Per gestire

gli utenti Samba autorizzati ad accedere al server si utilizza il comando

omonimo smbpasswd con il quale si posso aggiungere, cancellare utenti,

cambiare loro la password.

Samba deve coincidere con il nome di un utente denito nel sistema GNU/Linux, in quanto quest'ultimo deve essere sempre in grado di assegnare un proprietario valido agli eventuali le creati o copiati dal- l'utente connesso all'interno della risorsa condivisa.

Se ciò non è possibile si può ricorrere all'uso di un le di corrispondenza tra utenti GNU/Linux e utenti MS-Windows, il cui nome è indicato con la direttiva username map. Un valore abbastanza comune di tale parametro è smbusers. Tale le conterrà delle righe così formate:

nome_linux = nome_smb_1 nome_smb_2...

Per ovvi motivi di sicurezza, entrambi i le smbusers e smbpasswd, devono essere accessibili sia in scrittura che in lettura dal solo utente root. Livello di sicurezza server

security = server Con questa impostazione si ha lo stesso controllo di accesso visto nel caso di user con la dierenza che l'utenza viene con- trollata su un servente esterno (solitamente un PDC MS-Windows) il cui nome (NetBIOS) viene indicato con la direttiva password server.

security = domain Con questa impostazione si ha ancora lo stesso con- trollo di accesso visto nel caso di user, ma questa volta il servente Samba va a inserirsi in un dominio MS-Windows NT/2000.

Per aggiungere il server ad un dominio occorre fermare i demoni di Samba, quindi aggiungere il servente Samba al dominio NT sul PDC usando il server manager di MS-Windows NT oppure ad una active directory sul servente MS-Windows 2000 con la MMC (Microsoft Man- agement Console) attraverso lo strumento Utenti e computer di Active Directory. A questo punto si deve eseguire il comando:

smbpasswd -j nome_dominio -r nome_server -Unome_utente%parola_d'ordine

Il nome_dominio deve essere lo stesso indicato nella direttiva work- group di smb.conf, il nome_server deve coincidere con il valore di password server, nome_utente e relativa parola_d'ordine devono rap- presentare un'utenza con privilegi sucienti ad aggiungere un'utenza nuova nella macchina MS-Windows NT/2000.

Ultimate queste operazioni occorre naturalmente riavviare il servizio Samba.

Il vantaggio principale dell'impostazione domain rispetto a quella serv-

er consiste nel fatto che il PDC risulta meno carico, in quanto non è più

necessaria una connessione di rete permanente tra esso e il server Sam-

ba. Quest'ultimo infatti eettua una chiamata RPC solo al momento

stsamba:\

:mx=0:\

:sh:\

:sd=/var/spool/lpd/stsamba:\

:lp=/dev/null:\

:af=/var/spool/lpd/stsamba/acct:\

:if=/usr/bin/smbprint:

Figura 1.15: smb.conf: uso stampante Windows con client Linux

dell'autenticazione e non necessita di essere costantemente connesso al PDC come avviene nel caso del livello di sicurezza server.

Per concludere occorre notare che comunque che questo tipo di im- postazione (come nell'ipostazione server) è necessario tenere allineati gli elenchi degli utenti dal lato MS-Windows e dal lato GNU/Linux (il motivo è stato illustrato nel paragrafo del livello user). Ci sono però due direttive della sezione global che permettono di automatizzare l'aggiornamento degli utenti GNU/Linux:

• add user = script_1 %u

• delete user = script_2 %u

La prima entra in azione quando, a seguito di una connessione di un cliente MS-Windows, Samba si rivolge al server di dominio per l'aut- enticazione con esito positivo ma l'utente GNU/Linux corrispondente non esiste, ovviamente lo script script_1 deve essere scritto in mo- do adeguato anché crei l'utente ricevendolo come parametro dalla variabile %u.

In modo speculare si usa l'altra direttiva che entra in azione quando, a seguito di una connessione di un cliente MS-Windows, Samba si rivolge al server di dominio per l'autenticazione con esito negativo ma il cor- rispondente utente GNU/Linux esiste, in questo caso script_2 deve provvedere a cancellare l'utente in questione.

Per usare su una macchina GNU/Linux una stampante condivisa da una macchina MS-Windows, occorre impostare in modo opportuno il le di denizione delle stampanti GNU/Linux: /etc/printcap.

In gura 1.15 è illustato un esmpio di congurazione da aggiungere a smb.conf per consentire ad una stampante Windows di essere utilizzata da client Linux

Il signicato dei parametri di congurazione elencati in g 1.15 è il

seguente

• sd= indica la directory della coda per questa stampante;

• lp=/dev/null indica che la stampante non è collegata ad alcuna porta (non è locale);

• af= indica il nome del le per registrare le transazioni;

• if= indica il nome del ltro da usare per la stampa; quello usato nel- l'esempio è un ltro fornito in modo predenito con la distribuzione Red Hat all'interno del pacchetto samba-client.

Anché il tutto funzioni è poi necessaria la presenza del le .cong nella directory della coda indicata con la riga sd=. Un esempio del suo contenuto è il seguente:

share="//server_smb/nome_stampante_condivisa"

user="tizio"

password="password"\

1.6 Applicazioni che costituiscono Samba

La versione di Samba che viene presa in esame è la 3.0.8. I pacchetti com- ponenti la suite sono (si fa riferimento a pacchetti RPM essendo le prove state eettuate su macchine dotate di una distribuzione GNU/Linux fc2, x.y.z rappresenta il numero di versione):

samba-x.y.z.i386.rpm contiene i demoni nmbd e smbd che sono alla base del funzionamento di un servente Samba e alcuni programmi di servizio come smbadduser, smbstatus;

samba-client-x.y.z.i386.rpm contiene altri programmi di servizio come nmblookup, smbclient, smbmount, smbumount, smbtar, ndsmb, test- parm;

samba-common-x.y.z.i386.rpm nel pacchetto samba-common si trovano tra altri elementi il programma smbasswd e il le di congurazione di Samba /etc/samba/smb.conf precompilato con alcune impostazioni predenite.

samba-swat-x.y.z.i386.rpm nel pacchetto samba-swat si trova l'utility SWAT

(descritta in seguito) per la gestione e la condurazione dei demoni smb

e nmbd tramite interfaccia graca

Il server Samba si basa principalmente su due demoni (smbd e nmbd) che sono stati ampiamente descritti in precedenza.

Oltre a questi due demoni fanno parte della suite Samba numerosi pro- grammi ausiliari tra cui si ricoradano:

smbclient smb client utility è una applicazione ftp-like per sistemi linux, us- ata per prelevare e inserire le da e nelle condivisioni Windows. Questa utility serve per mostrare il contenuto di una directory condivisa, in- oltre può (nel caso di le testuali) eettuare la conversione end-of-line come nel caso dei trasferimenti text in ftp. smbclient può anche stam- pare su una stampante Windows condivisa, questo pacchetto è il cuore principale del lo script smbprint. smbclient non è un un utility user- friendly , al contrario è spesso utilizzata in altri script e chiamata da altre applicazioni come smbtar (utility per fare backup) e smbprint.

smbfs I sistemi *niX possono supportare a livello di kernel il supporto per SMB File System, per accedere alle condivisioni di Windows. Un le sistem Windows può essere montato e utlizzato con metodologie simili a quelle applicate per lesystem NFS, ovviamente ci sono alcune signif- icanti dierenze. NFS mantiene infatti sulle risorse condivise i permessi relativi agli utenti, al contrario smbfs non ha il concetto di permesso utente. La connessione ad una risorsa Windows avviene tramite un username e una password, che devo essere specicati all'istante della connessione. Il comando mount di linux non prevede la funzionalità aggiuntiva della specica di username e password. Samba fornisce un utility detta smbmount che permette di stabilire la connessione alla risorsa e montare il le system remoto. Smbmount crea anche un de- mone che provvede una automatica riconnessione alla risorsa nel caso di una perdita di connettività dovuta a un failvover della rete (il demone di controllo della connessione non era presente nelle prime versioni di Samba).

SMB Wrapper Altro componente molto interessante della suite Samba è

smbwrapper. Utilizzando questa libreria durante il link di un program-

ma, le risorse condivise di Windows risultano accessibili con le normali

librerie di funzioni open read close. La libreria smbwrapper è inclusa in

molti programmi come ad esempio midnight commander. Un altro van-

taggio di smbwrapper è che esso funziona su tutte le piattaforme *NIX,

al contrario di smbfs che è tipico solamente di piattaforme unix. Lo

svantaggio di smbwrapper è che le connessioni alle risorse non possono

essere utilizzate da più processi contemporaneamente. Se due appli-

cazioni hanno lo stesso le aperto questo richiede due sessioni con lo

stesso le server, abbiamo così una diminuzione delle prestazioni poichè

bisogna mantentere attive più connessioni contemporaneamente.

Figura 1.16: SWAT homepage

SWAT Quando ci si appresta a congurare approfonditamente un server Samba ci si scontra inevitabilmente con la grande quantita di opzioni globali e di share. Ricordarsi un prospetto a mente può risultare sco- modo e complicato, a questo scopo ci si può avvalere di un comodo tool graco di congurazione, Swat (Samba Web Administation Tool) che viene comunemente installato con il pacchetto samba-swat.

Una volta eseguite una semplice congurazione dell'utility si può aprire il browser all'indirizzo: http://localhost:901/. Si presenterà un

nestra nella quale è necessario eettuare il login dell'account root.

Come si può notare in g 1.16 si avrà immediatamente accesso ad una serie di menu che consentono di controllare varie opzioni tra cui share, utenti, parametri generali di congurazione del server Samba.

Per ogni opzione si ha a disposizione un link ad alcune pagine di docu-

mentazione relative al comando selezionato. Attraverso SWAT è inoltre

possibile acccedere ad una grande quantità di altra documentazione

come manuali, man-pages, how-to.

Figura 1.17: SWAT wizard

Va ricordato che nonostante sia possibile collegarsi anche da macchine remote, swat non ha di default la possibilità di usare password crit- tografate con conseguente pericolo di sning delle stesse. Esiste la possibilità di criptare le password anche se swat non lo supporta nati- vamente. Si può trovare un breve how-to introduttivo su [17]. Un'altro grande difetto di swat è che utilizzato su un le esistente ne modicherà anche il layout. Tutti i commenti eventualmente aggiunti e le opzioni include e copy verranno cancellati.

Webmin Webmin e' un semplice tool web-based che permette, attraverso

un interfaccia molto user-friendly, di poter amministrare praticamente

l'intero sistema nix. E' anche un ottimo strumento didattico, in quan-

to permette di vericare la sintassi di le di congurazione e le fun-

zionalità di servizi e programmi vari, editandoli tramite una intuitiva

interfaccia graca. E' composto da un server web (che di default la-

vora sulla porta 10000) e da numerosi CGI scritti in Perl che agiscono

direttamente su le di sistema come /etc/inetd.conf e /etc/passwd. .