Samba, Cups e Netatalk: condivisione di risorse in ambito ... · UNIVERSITÁ DEGLI STUDI DI MODENA E REGGIO EMILIA acoltàF di Ingegneria - Sede di Modena Corso di Laurea in Ingegneria

UNIVERSITÁ DEGLI STUDI DI MODENAE REGGIO EMILIA

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 31.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Funzionamento: una generica sessione Samba . . . . . . . . . 10

1.3.1 Concetti di Windows Networking . . . . . . . . . . . . 101.3.2 File sharing & print sharing . . . . . . . . . . . . . . . 111.3.3 Samba Printing . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Analisi pacchetti . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.1 Netbios e Netbeui . . . . . . . . . . . . . . . . . . . . 151.4.2 Autenticazione . . . . . . . . . . . . . . . . . . . . . . 181.4.3 Dettaglio pacchetti . . . . . . . . . . . . . . . . . . . . 19

1.5 Esempio di con�gurazione di Samba . . . . . . . . . . . . . . 251.6 Applicazioni che costituiscono Samba . . . . . . . . . . . . . . 321.7 Evoluzione di Samba: CIFS . . . . . . . . . . . . . . . . . . . 37

2 Netatalk 392.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2 AppleTalk e lo standard ISO/OSI . . . . . . . . . . . . . . . . 39

2.2.1 Una implementazione del protocollo Appletalk . . . . 492.3 Compilazione e installazione di Netatalk . . . . . . . . . . . . 492.4 Con�gurazione di Netatalk . . . . . . . . . . . . . . . . . . . . 50

2.4.1 Con�gurazione di AppleTalk Routing . . . . . . . . . . 512.4.2 Con�gurazione di un File Server . . . . . . . . . . . . 542.4.3 Principali Utility di Netatalk . . . . . . . . . . . . . . 57

3 Cups 603.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.1.1 Introduzione a IPP . . . . . . . . . . . . . . . . . . . . 603.2 Concetti generali . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.1 PostScript . . . . . . . . . . . . . . . . . . . . . . . . . 623.2.2 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.2.3 Spooler e Demoni di Stampa . . . . . . . . . . . . . . 643.2.4 File PPD . . . . . . . . . . . . . . . . . . . . . . . . . 64

1

INDICE 2

3.3 Struttura di CUPS . . . . . . . . . . . . . . . . . . . . . . . . 643.4 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5 Con�guration File . . . . . . . . . . . . . . . . . . . . . . . . 66

3.5.1 Con�gurazione del server HTTP . . . . . . . . . . . . 663.5.2 File di con�gurazione per stampanti . . . . . . . . . . 673.5.3 Tipologie MIME supportate . . . . . . . . . . . . . . . 71

3.6 CUPS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.7 Berkeley and System V Commands . . . . . . . . . . . . . . . 74

3.7.1 lpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.7.2 lp status . . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.3 lpc status . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.4 lpq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.5 lprm e cancel . . . . . . . . . . . . . . . . . . . . . . . 753.7.6 lpadmin . . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.7 cupsaddsmb . . . . . . . . . . . . . . . . . . . . . . . . 763.7.8 lpinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.8 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.8.1 foomatic . . . . . . . . . . . . . . . . . . . . . . . . . . 773.8.2 pap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.9 CUPS Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . 773.10 Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.10.1 Samba Backend . . . . . . . . . . . . . . . . . . . . . . 783.11 Network Printing . . . . . . . . . . . . . . . . . . . . . . . . . 81

Bibliogra�a 86

Capitolo 1

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 sumolte piattaforme (GNU/Linux, Mac Os-X, Solaris, HP-UX, AIX, True64,*BSD, e altre ancora), implementando un server SMB. SMB è un famosoprotocollo di condivisione delle risorse adottato sul �nire degli anni Ottantada molti produttori per fornire funzionalità di condivisione di �le, directorye stampanti all'interno di una rete locale. Tra questi produttori c'era ancheMicrosoft, che decise di includere il protocollo all'interno del suo sistemaoperativo Windows per l'erogazione dei servizi di rete. La scelta si rivelòstrategica per la casa di Redmond che ra�orzò il supporto a SMB in tutte lerelease successive dei propri sistemi operativi. Oggi SMB è più che mai pre-sente nei sistemi Microsoft anche se recentemente ha cambiato il suo nomein CIFS (Common Internet File System)[2].

Un Protocollo onnipresente Come conseguenza naturale dell'adozionedi SMB da parte di Microsoft, attualmente esistono svariati milioni di com-puter Windows che fanno uso di questo protocollo, creando così uno standarddi 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 unaunità condivisa da Windows, si sta in qualche modo utilizzando il protocolloSMB. Nonostante la presenza quasi esclusiva in ambito Windows, SMB è unprotocollo aperto e non un sistema chiuso sotto la proprietà di Microsoft.Qualunque produttore o gruppo di sviluppo può implementarlo per fornireservizi di condivisione su qualunque sistema e piattaforma, garantendo unapiena compatibilità Windows. Questo è proprio quello che fa il progettoSamba: fornire servizi di condivisione per accedere in maniera trasparente

3

CAPITOLO 1. SAMBA 4

alle reti Windows da postazioni Unix e viceversa. Il progetto esiste da lun-go tempo ma si può certamente a�ermare che la di�usione più rilevante diSamba si ha con la versione 2.2 nella piattaforma Linux. Il successo è statodato dalla credibilità del sistema operativo stesso e dall'allettante possibilitàdi replicare quasi completamente le funzionalità di un server Windows NT4senza sostenere costi di licenza. Installando Samba in un �le server era pos-sibile risparmiare subito circa mille euro di licenza Windows Server più tuttele CAL[3] 1 richieste per ogni client che accede ai servizi centralizzati. Unvantaggio non indi�erente per piccole e medie imprese, organizzazioni senzascopo di lucro ed enti governativi.

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

e le funzioni di browsing necessarie per l'elenco dei computer in Risorse diRete. Non bisogna infatti dimenticare che questo elenco non è dinamico eneppure aggiornato in tempo reale, ma è piuttosto mantenuto da un comput-er sulla rete. Questo a intervalli regolari provvede ad aggiornare l'elenco inbase a un algoritmo ben de�nito. I client fanno riferimento a questo elencoper visualizzare l'elenco dei membri della rete locale. E' per questo motivoche non sempre si riesce a vedere in rete un computer appena acceso o sitrovano ancora in elenco computer che risultano invece spenti già da diversiminuti. I demoni smbd e nmbd svolgono nel complesso la totalità delle fun-zioni presenti in Samba 2, garantendo un comportamento simile a quello diun server Windows NT4. Samba 2.2 può svolgere funzioni di workgroup odi PDC, può autenticare gli utenti in modalità debole compatibile Windows9x, può autenticare in modalità NT, supporta la browsing list e gestisce inbuona misura i criteri di sistema, come verrà spiegato in seguito. Il PrimaryDomain Controller (PDC) è il server che mantiene un database di tutte lepassword (SAM)3: quando un client cerca di accedere alle risorse di un serv-er, quest'ultimo veri�ca sul PDC se login e password fornite sono valide. Sequesto accade al client viene permesso l'accesso alle risorse richieste e fornitoun token di autenticazione con cui automaticamente riesce ad accedere adaltre risorse accessibili. Il database delle password viene automaticamentecopiato ad uno o più Backup Domain Controller (BDC) eventualmente pre-

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

2Il servizio che nelle reti Microsoft viene utilizzato per la traduzione dei nomi inindirizzi.

3Security Account Manager: sistema per la memorizzazione delle password e datiaccount utente in un dominio Microsoft

CAPITOLO 1. SAMBA 5

senti nella rete i quali possono essere utilizzati per autenticare i client nel casoin cui il PDC risulti inaccessibile. Sul server si possono poi con�gurare unnumero arbitrario di condivisioni e creare tutti i presupposti per l'erogazionedi cartelle pubbliche e di home directory, tutte protette con diritti a livellodi utente. Quanto basta insomma per sostituire un server NT4 in moltesituazione reali. La con�gurazione e la manutenzione del sistema Sambaavviene, secondo la tradizione Unix, tramite �le testuali da editare man-ualmente. Esistono comunque strumenti gra�ci per sempli�care la gestionedi Samba. Tra questi è interessante Swat, un front-end Web per l'ammin-istrazione del sistema, che verrà analizzato in seguito. Pur essendo moltofunzionale, Samba 2.2 è comunque privo di alcune caratteristiche importan-ti. Non è per esempio contemplato il ruolo di BDC, non sono supportatele relazioni di �ducia tra server Windows e server Samba e non è possibileamministrare la lista degli utenti e dei gruppi usando il tool di gestione diWindows NT4. Il divario si è poi allargato, dal momento che Microsoft nonsi è fossilizzata sulle caratteristiche di Windows NT4, ma ha incrementatopiuttosto la rosa di funzionalità di rete nelle successive release di Windows2000 Server e Windows Server 2003.

La versione corrente: Samba 3 Gli equilibri sono stati nuovamenteripristinati con Samba 3, rilasciato nel settembre 2003. Questa versione hacolmato un elevato numero di carenze, guadagnando nuovamente terrenosull'o�erta Microsoft e tornando nuovamente a essere un'alternativa interes-sante. Il progetto è stato in seguito aggiornato �no all'attuale 3.0.8. Questerelease successive hanno comunque avuto solo ruoli correttivi nei confrontidi bug strutturali o di falle di sicurezza[4]. Con questa versione delle suiteSamba è stata aggiunta una funizionalità importante il supporto per ActiveDirectory 4. 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 (LightweightDirectory Access Protocol)5per 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 ilfunzionamento dei domini Windows non sono in realtà aperti, ma sono unsegreto industriale ben custodito da Microsoft, e quindi non esiste quindialcuna documentazione tecnica liberamente disponibile. Gli sviluppatori diSamba non possono fare altro che compiere esperimenti sui domini ed esam-inare il tra�co di rete per cercare di dedurre il comportamento dei protocolli.Si tratta di un estenuante lavoro di reverse engineering.

4Active 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].

5LDAP è un insieme di speci�che per un protocollo client-server per ottenerememorizzare informazioni centralizzate come Network Directory[6].

CAPITOLO 1. SAMBA 6

Nonostante il chiaro intento da parte del gruppo di sviluppo di emularecompletamente l'ambiente di Active Directory, in Samba 3 sono state svilup-pate anche le caratteristiche di dominio NT4. La scelta è derivata dallaseguente motivazione: esiste ancora una percentuale elevata di utenti NT4Server, addirittura superiore alle previsioni di Microsoft, ed è bene forniresupporto a questa categoria di utilizzatori. Bisogna considerare che la mag-gior parte delle PMI (Piccole e Media Industrie) non ha bisogno di tutte lecaratteristiche evolute di rete introdotte a partire da Windows 2000 Server.Un ambiente aperto, senza costi di licenza e in grado di emulare WindowsNT4 Server è già più che su�ciente 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 vengonopreservati anche i SID (Single Identi�er), gli identi�catori unici Windows disicurezza per gli oggetti gestiti sul server. Grazie a questa capacità i clientpotranno essere integrati in maniera trasparente e senza alcun lavoro sup-plementare. E' supportato sia il ruolo di PDC (presente già da tempo) chequello di BDC, una novità per Samba. I tool di amministrazione presenti suWindows possono essere usati per amministrare questo ambiente, rendendopiù semplice la gestione da parte dello sta� tecnico.

I domini creati con Samba non sono isolati, ma possono istituire relazionidi �ducia con controller di dominio basati su Windows. Questa era una dellecarenze più sentite in Samba 2.2, in quanto l'assenza delle trust impedival'uso di Samba in realtà complesse dotate di molti domini. I nomi delle risorsepossono essere composti ora in maniera più cosmopolita grazie all'inclusionedi unicode: esiste ora piena facoltà di avere nomi realmente internazionalicon alfabeti non occidentali. E' in�ne degna di nota la scelta di introdurre uncomando net ispirato all'omonimo comando Windows per l'esecuzione di ungran numero di funzioni di rete. L'obiettivo dichiarato è quello di sostituireprogressivamente la miriade di utility e comandi di supporto a Samba conle opzioni incorporate all'interno dell'unico comando net. Si tratta di unascelta interessante, che permette di sempli�care la gestione del sistema conun numero limitato di istruzioni da linea di comando.

Samba 3 può essere a tutti gli e�etti 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 anchemettere a disposizione proprie risorse a clienti MS-Windows o GNU/Linux.Più in dettaglio ecco quali sono i servizi o�erti da Samba: :

• server per o�rire 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);

CAPITOLO 1. SAMBA 7

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

1.2 Caratteristiche

Le caratteristiche principali o�erte 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 di�eren-ti tipologie Unix, Novell, NT eccetera. Samba permette di integrare serverGNU/Linux, BSD, o Unix (e altri) in una rete in cui si deve convivere conclient MS Windows senza dover installare software aggiuntivo sui client. Ilserver Samba viene percepito come un server Windows NT e consente dicondividere �le e stampanti su una rete Windows senza troppi sforzi. Sambaè inoltre ottimo come server di stampa, accopiato a CUPS o lpr permetteanche un sistema �essibile e avanzato di accounting delle stampe, ad esem-pio consentendo a macchine Windows di utilizzare stampanti installate sumacchine *niX o viceversa a macchinue *niX di stampare su risorse collegatea 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 allepiattaforme Windows di interoperare con le piattaforme server. Samba vieneperò anche sempre più utilizzato in sostituzione di File Server NT o Novellin quanto permette di ridurre sensibilmente i costi di licenza per l'accessodei client e ottenere un'alta a�dabilità del servizio. Infatti molti sistemi �leserver/print server/domain controller proprietari richiedono oltre al paga-mento di una licenza d'uso per il server in sè, anche di licenze di connessioneper ogni client che deve utilizzare tale server (CAL). Molte aziende possonopermettersi di impiegare un server basato sull'accoppiata Linux/Samba, inquanto le e�ettive necessità centralizzate sono generalmente limitate. Nonbisogna dimenticare che gran parte dei server NT o 2000 vengono utilizzatisolamente per le loro funzionalità di �le server. In pratica si sfrutta il sistemacome contenitore centralizzato dove salvare i documenti di lavoro e le cartellepersonali degli utenti, impiegando poi un sistema di storage per eseguire ilsalvataggio di tutta l'informazione aziendale in un colpo solo.

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

L'economicità di un sistema GNU/Linux riguarda soprattutto i requisitihardware 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-

CAPITOLO 1. SAMBA 8

dia dell'hardware, utilizzando GNU/Linux raddoppi da 3 a 6 anni (Win-dows richiede in media il raddoppio delle risorse hardware di versione inversione)[10].

Flessibilità Samba facilita le operazioni di consolidazione di più servizi suun singolo server. E' possibile anche con�gurare più istanze di Samba su unserver che abbia più interfacce di rete. Non solo, Samba è già predisposto perIP failover6, ed è estremamente �essibile e dotato di un numero eccezionaledi opzioni con cui ottimizzare il proprio server e con�gurarlo per fare lecose come più aggradano. Inoltre già dalla versione 2.2, Samba supportadi�erenti sistemi di autenticazione e salvataggio dei dati degli utenti. Sipossono mantenere gli account degli utenti sul classico �le smbpasswd, o sulpiù modermo ldap o tdbsam. Non dimentichiamo inoltre winbind un demoneche permette di utilizzare sulla macchina *nix gli utenti impostati su di undominio NT.

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

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 3Com3C905C. Per i test è stata utilizzata la suite di test Netbench 7.02, con�guran-do 30 client per generare su�ciente tra�co di rete. Su entrambe le macchineWindows e Linux sono stati eliminati i servizi non necessari (server web serveftp) inoltre sulla macchina Linux è stato ricompilato il kernel per eliminare imoduli non necessari. Sui due tipi di sistema non sono state eseguite parti-colari ottimizzazioni benchè entrambi possiedano di default impostazioni chepermettono 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 gra�co del tempo medio di risposta (�gura 1.2) a parità dihardware o�ra prestazioni migliori del concorrente. Nell'altro gra�co (�gura1.1) possiamo notare che servendo pochi client Samba e Windows presentinovalori di throughput praticamente uguali mentre al crescere del numero diHost samba fornisce prestazioni migliori.

6Se un server non risponde più alle richieste, può essere rimpiazzato da un altro che neacquisisce l'Ip, il tutto in maniera trasparente rispetto agli altri servizi di rete.

CAPITOLO 1. SAMBA 9

Figura 1.1: Troughput

Figura 1.2: Response time

CAPITOLO 1. SAMBA 10

1.3 Funzionamento: una generica sessione Samba

In questo paragrafo verrà analizzato il funzionamento di una generica ses-sione Samba e verranno introdotti alcuni concetti fondamentali di WindowsNetworking 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 unmodello di tipo broadcast. Un sistema che vuole partecipare ad una networkWindows di�onde il suo nome Netbios a tutti gli altri host della subnet incui è inserito. Se nessun altro sistema si oppone il nome è associato allamacchina e si può procedere al suo utilizzo.

Per identi�care un sistema dal nome, il nome richiesto è mandato inbroadcast per tutta la rete e il sistema che possiede il nome è l'unico arispondere.

Samba è in grado di fornire e partecipare a questi servizi sia per quantoriguarda 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 o�re per il Domain Naming Service. Grazie aquesto compontente si può ricavare l'indirizzo associato ad un nome netbios.

Ogni sistema Windows può avere più di un nome Netbios associato. Unnome identi�ca l'host, un'altro nome può essere associato all'utente loggatosul sitema.

Il sistema di registrazione dei nomi tramite broadcast funziona su retipiccole e su una singola subnet, ma genera molto tra�co e non è scalabile.Il browsing di una rete permette ad un utente di vedere i nomi degli hostsulla rete. Per fare ciò, l'host in questione deve aver ricevuto e memorizzatotutte le corrispondenze dei nomi della rete e host connessi.

Per questo motivo sono stati classi�cati gli host in master browser e nameserver. Per supportare il browsing della rete si usano i master browser, chemantengono in cache le informazioni di broadcast degli altri sistemi. Quandoun sistema vuole visitare le Risorse di rete non fa altro che interrogare ilmaster browser, senza generare tra�co super�uo. Il master browser è sceltotramite un processo di elezione. Se il master browser è riavviato o risultanon disponibile, si ha un elezione tra le workstation rimanenti per il ruolodi master browser. Samba può essere usato come master browser in unasessione di Windows networking, puo essere con�gurato sia per forzare unaelezione 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 di�erenti.


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

Il Windows Internet Naming Service (WINS) [11] serve a trasformarei nomi dei computer in indirizzi IP per l'instradamento e la consegna deipacchetti. WINS è studiato per a�rontare il problema dell'individuazionedi risorse di rete in ambiente TCP/IP attraverso la con�gurazione e il man-tenimento automatici delle tabelle di mappatura dei nomi NetBIOS e degliindirizzi IP, svolgendo insieme funzioni elementari come impedire la dupli-cazione di nomi in rete. WINS è un servizio complemetntare per il DHCP epossiede una strumentazione completa e centralizzata per l'amministrazionee la con�gurazione di server WINS, tabelle nomi statiche e informazioni diduplicazione.

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

Samba può quindi essere impostato per usare unWins 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 utilizzacome server wins.

1.3.2 File sharing & print sharing

La maggior parte dei modelli di �le sharing che sono o�erti nei sistemi Win-dows sono disponibili con Samba. Grazie al supporto di linux per le homedirectory, 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 dicontrollo di accesso:

• livello condivisione: a ogni disco, cartella, �le o stampante condivisaviene assegnata una password

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

Samba supporta entrambi i tipi di controllo di accesso, l'utente non notaquindi nessuna di�erenza rispetto a un server Windows e non necessita dialcun software aggiuntivo da installare sui client.

Samba o�re inoltre l'abilità di memorizzare i pro�li degli utenti all'internodelle condivisioni, grazie a ciò un utente può cambiare workstation e averecon lui le stesse impostazioni e preferenze (desktop, menu, ecc.).


1.3.3 Samba Printing

Oltre che alla condivisione di �le Samba, può essere usato per la condivisionedelle risorse di stampa. Samba fornisce quindi l'accesso alle macchine Win-dows delle stampanti Unix. Alcuni sistemi Windows devono inoltre essere ingrado di scaricare i driver di stampa dal server che condivide la stampante.Tutto ciò può essere fatto senza lavoro aggiuntivo dell'utente ma con unpiccolo setup iniziale. Se il sistema di stampa *niX è aggiunto ad alcuni pac-chetti di stampa postscript (come Ghostscript) allora è possibile per i sistemiWindows usufruire di servizi che altrimenti non avrebbero a disposizione.

Per gli utenti unix che vogliono stampare su macchine Windows è adisposizione l'utility smbprint, questa può essere chiamata dall'utente o usatacome �ltro.

Cenni sulla stampa Windows

Windows in origine fu sviluppato per un utilizzo da parte di un singoloutente, ciò signi�ca 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 eprogrammatori 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 (LPTad esempio) e inviare al suo interno dei dati. Questo sistema di stampapuò essere utilizzato da remoto tramite SMBsplopen, fornendo però solo unrudimentale supporto per il monitoraggio della coda di stampa. Tramiteil printing spooling path non è introdotto il concetto di driver nel sistemaoperativo, ciascun applicativo utilizza un driver a se stante per l'uso dellaperiferica.

Windows 3.x printing system Windows 3.x è stata la prima versione diWindows 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 APIdi Windows 3.1 sono state aggiunte nuove funzionalità che consentono unmaggiore controllo delle code di stampa (come pausa, cancellazione, puliziacoda di stampa).

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

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

• delle chiamate DCE/RPC sono e�ettuate alla pipe SPOOLSS per aprirela connessione alla stampante, creare nuova stampante, aggiungerne idriver.

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

Tutte le comunicazioni di stampa e�ettuate 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 elencatealcune della maggiori di�coltà nell'implementazione di questa struttura.

• l'impelementazione DCE/RPC è terribilmente complessa;


• il sistema di spooling è delicato e instabile, se vengono inviati ad essodati formattati non correttamente oppure dati inattesi, va irrimedia-bilmente in crash;

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

• non c'è protezione dalle race condition, ossia se due amministratoriinstallano dei driver contemporaneamente ciascuno può fare dannoall'altro.

Per far fronte alle problematiche sopra esposte, venne creata una sezionededicata nel progetto Samba chiamata Samba Printer Code la quale o�realcune 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à dellastampante. Conseguentemente ad ogni arrivo di job nella coda di stampauna nuova entry è aggiunta nel database. Il passo sucessivo del processo distampa consiste nel memorizzare i dai all'interno di un �le temporaneo. Perrilevare 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. Memorizzandonel database tdb le informazioni sull'ultimo stato della coda si può evitarel'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 iclassici strumenti (lpq, lprm, lpc).

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

• migliorare e arricchire le Unix printig API;

• migliorare i driver per le stampanti inkjet, (le stampanti con emulazionepostscript 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 funzionamentodi Samba.

1.4.1 Netbios e Netbeui

I protocolli NetBIOS ed NetBEUI [13] sono stati sviluppati rispettivamentenel 1983, dalla Sytek per IBM, e nel 1985 da IBM stessa. Ancora oggi restanomolto di�usi nei sistemi Microsoft, in virtù dei loro pregi nell'ambito dellereti locali.

Con l'introduzione di Token Ring, IBM nel 1985 de�nì delle estensioni aNetBios (NetBIOS Extended User Interface NetBEUI) che permettevano diappoggiarsi 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 ladi�usione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche suIPX e IP, oltre che su altri protocolli.

All'epoca, l'obiettivo era infatti quello di creare un protocollo su misuraper le LAN di dimensioni contenute (�no a circa 200 nodi), quindi dovevaessere piccolo, semplice, veloce e doveva permettere di assegnare nomi umanialle risorse, invece dei complessi indirizzi usati dal TCP/IP. Inoltre NetBIOSè stato progettato perchè usasse intensamente i broadcast (messaggi uno atutti), 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 appositimessaggi broadcast per farsi accettare come nuovo nodo attivo. Se il nome ègià usato, il precedente possessore di quel nome deve inviare un messaggio dirisposta per respingere la scelta. Se invece un computer vuole localizzare unnodo preesistente, invierà ancora altri broadcast nel tentativo di contattarequello speci�co nodo. Il computer remoto è sempre tenuto a rispondere ai


broadcast con un messaggio unicast (uno a uno). Solo successivamente i duecomputer potranno comunicare senza usare broadcast.

Per essere più precisi, l'implementazione del NetBEUI nei sistemi Mi-crosoft di�erisce 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 ditrasporto.

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

• nomi unici: possono essere usati per identi�care al più una sola risorsain rete

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

In ambiente Windows, un nome unico può individuare un computer dellarete, un utente loggato su un sistema della rete, sia anche un servizio o�ertoda 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 identi�care queste funzionalità viene riservato il sedicesimo carat-tere, che diventa un su�sso e quindi limita il nome a soli 15 caratteri. Lecomunicazioni sono di tre tipi: sessioni, datagrammi, broadcast. Le sessionisi 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 masenza dover stabilire una sessione. I broadcast in�ne, 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 datagrammisi è limitati a 512 byte per messaggio ed inoltre non si ha la garanzia che idati arrivino. Tuttavia, negli ambiti in cui queste limitazioni non costituis-cono un problema insormontabile, lavorare con i datagrammi rimane moltosemplice e veloce.

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

I limiti di Netbios over Netbeui La di�usione di Internet ha messosubito in luce quali sono i limiti di NetBIOS e del suo supporto NetBEUIquando la rete cresce di dimensioni. Tralasciando problemi seri ma noninsormontabili, 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 nomiuguali nella stessa rete, bisognerebbe trovare un nome diverso per ogni com-puter connesso, cosa non banale in una rete geogra�ca. 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 perraggiungerlo. Il problema in questo caso risiede nel fatto che i nomi NetBIOSnon contengono alcuna informazione gerarchica. In principio infatti il Net-BIOS fu pensato per reti semplici e non strutturate a di�erenza 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 nonpermettono il propagarsi dei broadcast, utili al protocollo NetBIOS quandocerca di localizzare un nodo.

Per evitare che il NetBIOS a�ondasse, tornò molto comodo a Microsoftil fatto di poter abbinare l'interfaccia NetBIOS ad un protocollo molto più�essibile del NetBEUI, come il TCP/IP, e limitando l'impiego del NetBEUInell'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 so�re delle limitazioni di cui parlavamo prima. Chiaramente sor-gono nuove complicazioni in seguito alle quali si ebbe la creazione dei serviziWINS (derivante dal servizio DNS di�uso in Internet) e la creazione del �leLMHOSTS (derivante da HOSTS) 7.

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/IPdeve usare indirizzi. Ecco che nasce il �NetBIOS over TCP/IP�, chiamatoanche NBT, descritto negli RFC 1001 e 1002 [14]. Esso è in grado di lavoraresu reti geogra�che, basandosi su associazioni tra nomi NetBIOS e indirizziIP fornitegli dall'esterno.

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

b-nodi (nodi broadcast) usano broadcast sia per la registrazione che perla risoluzione dei nomi in indirizzi IP. I b-nodi so�rono ancora delproblema 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 conrichieste unicast un server WINS noto. WINS, (Windows Internet

7Host File: �le locale memorizzato nel computer con sitema operativo Windows utiliz-

zato per tradurre il nome di dominio in indirizzo IPLmHost File: un �le locale memorizzato nel computer con sitema operativo Windowsutilizzato per il nome NetBIOS in indirzzo IP


Name Service, servizio nomi Internet Windows), è un server, che imi-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 ilbroadcast.

Una volta ricavati gli indirizzi IP corrispondenti ai nomi netbios, si pos-sono aggirare i limiti descritti in precedenza ed è così possibile contattare inodi 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 sidispone di nessun server WINS e non si riesce a risolvere un nome remototramite 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 retelocale. Infatti, per non essere obbligati a subire un'eccesso di broadcastsulla propria rete, è possibile precaricare le associazioni del �le LMHOSTSpiù usate nella cache. Nel protocollo TCP/IP, per stabilire una comuni-cazione, è necessario de�nire le porte a cui inviare le richieste. NBT usaprevalentemente 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 cosapuoò 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 di�er-enti tipi di integrazione tra i sistemi Windows e i sitemi Unix, per esempioSamba 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 reteWindows.

A causa della di�erenza dei sistemi di criptazione tra Windows e Unixnon è 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 livellidi autenticazione separati.

A causa della varità di sistemi di autenticazione delle macchine nix questafunzionalità richiede un sforzo di setup iniziale, ma consente di ottenere unvantaggio nell'eliminazione delle richieste di username e password agli utentie elimina la confusione di dover mantenere password diverse in ambientidiversi.

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

1.4.3 Dettaglio pacchetti

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

Cattura dei pacchetti in real time: durante questa fase è stato avviatoil programma (con privilegi di root)e sono stati impostati alcuni parametridi con�gurazione 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 scrollingin live capture, Enable MAC name resolution, Enable network name resolu-tion, Enable transport name resolution). Dopo questi settaggi si è iniziata lacattura delle immagini selezionando start capture dal menu del program-ma. Cessata la cattura dei pacchetti sono state analizzati i dati ottenutimediante salvataggio di �le in un formato compatibile con ethereal. La reteutilizzata 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) eun 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 nomenetbios PCXP all'interno del gruppo di lavoro WORKGROUP. Per indi-viduare la di�erenza tra nome della macchina e nome del gruppo di lavorobisogna analizzare i �ag del pacchetto nel dettaglio. Per i nomi host è attivoil �ag unique, mentre per i nomi del workgroup è attivo il �ag group comesi 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 latipologia di sitema operativo (NT Workstation).

Prima di procedere nella descrizione del funzionamento del processo dielezione del master browser è necessario descriverne il funzionamento neldettaglio.

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

Master Browser mantiene la lista principale di tutti i computers e delleshares della rete. Tutti i Workgroup o i Domini hanno un masterbrowser;


Figura 1.6: �ag unique e �ag group

Domain Master Browser il master browser per un dominio. Il PDC deldominio 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 unacopia della lista delle risorse al backup browser nel caso di failure delmaster;

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

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 ognimomento, il master browser locale aggiorna continuamente la lista e la inviaalle macchine che ne fanno richiesta. Il master browser di dominio inveceraccoglie le liste di ogni sottorete e le mette a disposizione dei master browserlocali.

Un elaboratore diventa master browser locale a seguito di una elezioneche può essere e�ettuata 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 con�gurato come Preferred Master

nuovo elaboratore si presenta in rete). Riguardo a tale elezione Microsoftassegna ai suoi sistemi operativi un valore, detto livello, che cresce sempredi 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 livello17, una con MS-Windows NT 4-Server ha livello 32, una con MS-Windows2000-Server ha livello 64).

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

Con Samba il livello per la partecipazione all'elezione può essere scelto insede di con�gurazione. Nell'esempio seguente vengono mostrate le direttiveda inserire nella sezione [global] del �le smb.conf a�nché il server Sambasia master browser locale prevalendo su macchine MS-Windows �no aalla ver-sione NT-server: Dopo l'avvio del computer si può notare come esso annuncise stesso in rete e le sue caratteristiche per partecipare (ed eventualmentevincere)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 richiestain broadcast nella subnet per l'avvio del processo elettivo.

Come si può osservare nel dettaglio del pacchetto n 34 (�g 1.10) serversmbrisponde alle query sul processo elettivo. Da notare in particolare come ilserver Samba con la con�gurazione precedente si presenti in rete come unBrowse server in standby identi�cato come Windows NT Workstation.

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

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

Nei pacchetti dal 68 al 72 (visibili in �g 1.13) si instaura la connessionevera e propria (lo si intuisce anche dall' utilizzo del protocollo SMB). Primadell'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


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


32 35.744439 192.168.1.20 192.168.1.255


33 35.744569 192.168.1.20 192.168.1.255


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 richiestadi connessione al server SMB (NBSS Netbios Session Service)

1.5 Esempio di con�gurazione di Samba

In questo paragrafo verrà descritta la con�gurazione di Samba utilizzandocom esempio la descrizione di un �le di con�gurazione. La con�gurazione diSamba (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 con�gurazione vengono forniti nella forma opzione =valore Il �le viene diviso in più sezioni delimitate da un nome traparentesi quadre che de�niscono una share (condivisione), oltre allasezione generale [global];

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

• I paramteri di con�gurazione possono estendersi su più righe di smb.confutilizzando 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


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


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 chespazi vuoti;

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

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

Le opzioni di con�gurazione possono essere di due tipi fondamentali:

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

• share appaiono all'interno di speci�che share e de�niscono il com-portamento riguardo alla speci�ca share. Se appaiono in [global]

de�niscono i comportamenti di default per ogni share.

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

1. [global] Sempre presente, di solito ad inizio �le, de�nisce le opzionidi default valide per tutte le condivisioni (possono essere sovrascritteda opzioni presenti nelle speci�che sezioni) e i parametri generali dicon�gurazione del server

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

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

Oltre a queste sezioni speciali ne possono esistere altre, il nome di ognisezione coincide con il nome della relativa condivisione, così come appareal client SMB. In �gura 1.14 è illustrato un semplice esempio del principale�le di con�gurazione di Samba smb.conf . La distribuzione utilizzata perl'esempio è Fedora core 2.

Di seguito una breve spiegazione della con�gurazione della suite Sambarelativa 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 utentiWindows 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 risoluzionedei 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 ilnominativo-utente dalla direttiva valid users eventualmente inseritanella 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 frai 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 abbianogli stessi diritti sui �le condivisi (con l'impostazione guest account =utentesmb il proprietario delle risorse condivise sarà sempre l'utenteGNU/Linux utentesmb qualunque sia il nominativo dell'utente MS-Windows che si connette).

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

Il controllo delle utenze viene e�ettuato dal server Samba in base al con-tenuto del �le dei suoi utenti che solitamente è smbpasswd. Per gestiregli utenti Samba autorizzati ad accedere al server si utilizza il comandoomonimo smbpasswd con il quale si posso aggiungere, cancellare utenti,cambiare loro la password.


È di fondamentale importanza notare che comunque il nome utenteSamba deve coincidere con il nome di un utente de�nito nel sistemaGNU/Linux, in quanto quest'ultimo deve essere sempre in grado diassegnare 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 corrispondenzatra utenti GNU/Linux e utenti MS-Windows, il cui nome è indicatocon la direttiva username map. Un valore abbastanza comune di taleparametro è 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 utenteroot. Livello di sicurezza �server�

security = server Con questa impostazione si ha lo stesso controllo diaccesso visto nel caso di user con la di�erenza che l'utenza viene con-trollata su un servente esterno (solitamente un PDC MS-Windows) ilcui 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 serventeSamba va a inserirsi in un dominio MS-Windows NT/2000.

Per aggiungere il server ad un dominio occorre fermare i demoni diSamba, quindi aggiungere il servente Samba al dominio NT sul PDCusando il server manager di MS-Windows NT oppure ad una activedirectory sul servente MS-Windows 2000 con la MMC (Microsoft Man-agement Console) attraverso lo strumento �Utenti e computer di ActiveDirectory�. 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 dipassword server, nome_utente e relativa parola_d'ordine devono rap-presentare un'utenza con privilegi su�cienti ad aggiungere un'utenzanuova nella macchina MS-Windows NT/2000.

Ultimate queste operazioni occorre naturalmente riavviare il servizioSamba.

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 e�ettua 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 alPDC 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 allineatigli elenchi degli utenti dal lato MS-Windows e dal lato GNU/Linux(il motivo è stato illustrato nel paragrafo del livello user). Ci sonoperò due direttive della sezione global che permettono di automatizzarel'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 uncliente MS-Windows, Samba si rivolge al server di dominio per l'aut-enticazione con esito positivo ma l'utente GNU/Linux corrispondentenon esiste, ovviamente lo script script_1 deve essere scritto in mo-do adeguato a�nché crei l'utente ricevendolo come parametro dallavariabile %u.

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

Per usare su una macchina GNU/Linux una stampante condivisa dauna macchina MS-Windows, occorre impostare in modo opportuno il �ledi de�nizione delle stampanti GNU/Linux: /etc/printcap.

In �gura 1.15 è illustato un esmpio di con�gurazione da aggiungere asmb.conf per consentire ad una stampante Windows di essere utilizzata daclient Linux

Il signi�cato dei parametri di con�gurazione elencati in �g 1.15 è ilseguente


• mx=0 indica nessun limite di grandezza dei �le da stampare;

• 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 prede�nito con la distribuzioneRed Hat all'interno del pacchetto samba-client.

A�nché il tutto funzioni è poi necessaria la presenza del �le .con�g nelladirectory 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 provestate e�ettuate 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 basedel funzionamento di un servente Samba e alcuni programmi di serviziocome smbadduser, smbstatus;

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

samba-common-x.y.z.i386.rpm nel pacchetto samba-common si trovanotra altri elementi il programma smbasswd e il �le di con�gurazionedi Samba /etc/samba/smb.conf precompilato con alcune impostazioniprede�nite.

samba-swat-x.y.z.i386.rpm nel pacchetto samba-swat si trova l'utility SWAT(descritta in seguito) per la gestione e la con�durazione dei demoni smbe nmbd tramite interfaccia gra�ca


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. Questautility serve per mostrare il contenuto di una directory condivisa, in-oltre può (nel caso di �le testuali) e�ettuare la conversione end-of-linecome nel caso dei trasferimenti text in ftp. smbclient può anche stam-pare su una stampante Windows condivisa, questo pacchetto è il cuoreprincipale del lo script smbprint. smbclient non è un un utility user-friendly , al contrario è spesso utilizzata in altri script e chiamata daaltre applicazioni come smbtar (utility per fare backup) e smbprint.

smbfs I sistemi *niX possono supportare a livello di kernel il supporto perSMB File System, per accedere alle condivisioni di Windows. Un �lesistem Windows può essere montato e utlizzato con metodologie similia quelle applicate per �lesystem NFS, ovviamente ci sono alcune signif-icanti di�erenze. NFS mantiene infatti sulle risorse condivise i permessirelativi agli utenti, al contrario smbfs non ha il concetto di permessoutente. La connessione ad una risorsa Windows avviene tramite unusername e una password, che devo essere speci�cati all'istante dellaconnessione. Il comando mount di linux non prevede la funzionalitàaggiuntiva della speci�ca di username e password. Samba fornisce unutility detta smbmount che permette di stabilire la connessione allarisorsa e montare il �le system remoto. Smbmount crea anche un de-mone che provvede una automatica riconnessione alla risorsa nel caso diuna perdita di connettività dovuta a un failvover della rete (il demonedi controllo della connessione non era presente nelle prime versioni diSamba).

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 normalilibrerie di funzioni open read close. La libreria smbwrapper è inclusa inmolti 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. Losvantaggio di smbwrapper è che le connessioni alle risorse non possonoessere utilizzate da più processi contemporaneamente. Se due appli-cazioni hanno lo stesso �le aperto questo richiede due sessioni con lostesso �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 con�gurare approfonditamente un serverSamba ci si scontra inevitabilmente con la grande quantita di opzioniglobali e di share. Ricordarsi un prospetto a mente può risultare sco-modo e complicato, a questo scopo ci si può avvalere di un comodotool gra�co di con�gurazione, Swat (Samba Web Administation Tool)che viene comunemente installato con il pacchetto samba-swat.

Una volta eseguite una semplice con�gurazione dell'utility si può aprireil browser all'indirizzo: http://localhost:901/. Si presenterà un�nestra nella quale è necessario e�ettuare il login dell'account root.Come si può notare in �g 1.16 si avrà immediatamente accesso ad unaserie di menu che consentono di controllare varie opzioni tra cui share,utenti, parametri generali di con�gurazione del server Samba.

Per ogni opzione si ha a disposizione un link ad alcune pagine di docu-mentazione relative al comando selezionato. Attraverso SWAT è inoltrepossibile acccedere ad una grande quantità di altra documentazionecome manuali, man-pages, how-to.


Figura 1.17: SWAT wizard

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

Webmin Webmin e' un semplice tool web-based che permette, attraversoun interfaccia molto user-friendly, di poter amministrare praticamentel'intero sistema nix. E' anche un ottimo strumento didattico, in quan-to permette di veri�care la sintassi di �le di con�gurazione e le fun-zionalità di servizi e programmi vari, editandoli tramite una intuitivainterfaccia gra�ca. E' composto da un server web (che di default la-vora sulla porta 10000) e da numerosi CGI scritti in Perl che agisconodirettamente su �le di sistema come /etc/inetd.conf e /etc/passwd. .


Figura 1.18: Plugin Samba per Webmin

Webmin puo' essere compilato tranquillamente su una grande varieta'di sistemi operativi, da Linux alle piu disparate versioni di Unix, com-preso il mac OS X. La sua natura modulare ha permesso la creazionedi innumerevoli plug-in in grado di gestire e con�gurare diversi servizi.Tra questi plugin molto interessante è quello per la gestione della suiteSamba visibile in �gura 1.18. Tramite questo tool si possono con�gu-rare una molteplicità di opzioni tra cui le share, il merge delgi utentinix con quelli Samba la condivisione delle stampanti.

SMB4k Smb4k prelevabile da [18] è un browser per le condivisioni Windows(SMB) per l'ambiente desktop KDE (è possibilie comunque utilizzarlosotto altri ambiente come Gnome e Xfce). Smb4k fa uso della suiteSamba per accedere alle risorse smb presenti sulla rete locale: è unostrumento completo e al contempo semplice da utilizzare.

Al momento Smb4K supporta linux e FreeBsd (quest'ultimo in fasesperimentale). Tra le principali feature: possibilità di scansione work-group (visibile in �g 1.19), accesso ai �le via Konqueror, operazioni dimount e umount attivabili tramite un semplice click, supporto dellecondivisioni stampanti smb, possibilità di personalizzazione di user-name e passwdord per l'accesso alle share.


Figura 1.19: Smb4k

1.7 Evoluzione di Samba: CIFS

CIFS, è una novità su cui sta lavorando Microsoft insieme ad altre società(quali AT&T, SCO, Intel, Digital Equipment, Data General). Si tratta di unprotocollo basato su SMB, ma orientato verso Internet e mira ad aggiungersiai sistemi classici di accesso ai �le (FTP,HTTP, NFS). CIFS è un acronimo,il suo nome sta per Common Internet File System

Common inteso nel senso di usato comunemente, infatti tutte le versionidi Windows abbastanza recenti hanno incluso una primitiva imple-mentzione di CIFS. Le speci�che sono aperte: l'intento è che diventinoun RFC e vengano implementate su tutte le piattaforme, incluse quelleMicrosoft e Unix. Sfortunatamente c'è ancora poca documentazionecorretta e autorizzata a riguardo.

Internet Al momento in cui il termine CIFS venne coniato la teconologiautilizzata da Microsft per le comunicazioni via rete era basata su pro-tocolli netbios scarscamente applicabili a grandi reti. CIFS vuole dareuna svolta a questa situazione ad esempio utilizzando per il servizio dinaming DNS.

File System CIFS permette la condivisione di directory, stampanti e �lesystem tramite la rete internet.


I vantaggi dichiarati consisterebbero in un accesso multiplo in scrittura ai�le senza perdita di integritàe coerenza, robustezza, buona velocità, sicurezzanegli accessi, supporto dei caratteri in formato Unicode, uso di nomi consigni�catività globale per i �le, possibilità di hard-link del �lesystem.

Al giorno d'oggi esistono diverse implementazioni del protocollo CIFS,molte delle quali rispettano le speci�cha fornite da SNIA [19]. L'implemen-tazione *niX più di�usa di questo protocollo è CIFS VFS il cui sito u�cialedi riferimento è http://linux-cifs.samba.org/. CIFS VFS è distribuitosotto licenza GNU GPL. Al contrario di altri �lesystem di rete, CIFS ele relative impostazioni di autenticazione e autorizzazzione sono supportatee integrate a livello di kernel. Linux-CIFS è infatti stato approvato daglisviluppatori del Kernel Linux già dalla versione 2.6.7. Le attuali implemen-tazioni di CIFS non o�rono supporto per vecchie installazioni di �le serverSMB, motivo per cui all'interno di uno stesso sistema possono coesistereversioni di�erenti di SMB e CIFS.

Capitolo 2

Netatalk

2.1 Introduzione

Uno dei grandi vantaggi di Macintosh rispetto ai normali PC è la disponibil-ità su ogni macchina di software e hardware di rete, per scambiare dati tracalcolatori, presenti �n dalle prime versioni di tale sistema operativo. Tutti iMacintosh, vengono dotati di serie dell'elettronica necessaria per scambiaredati da macchina a macchina. Il sistema operativo Mac OS, dalla versione7.0 in poi, e consente di condividere applicazioni e documenti con grandefacilità tramite l'utilizzo di una rete detta AppleTalk. AppleTalk fu svilup-pato nei primi anni 80 dai laboratori Apple. E' uno standard proprietarioper l'interconnessione tramite rete di elaboratori Machintosh. AppleTalkspeci�ca uno stack protocollare che consente di dirigere e organizzare il �us-so di dati attraverso una rete. Apple Computer usa il nome AppleTalk perriferirsi a Apple Network Protocol Architecture. Lo standard AppleTalkseppur prorpietario venne presto pubblicato e pubblicizzato per consentirneimplementazione e sviluppo sotto altre piattaforme. AppleTalk è implemen-tato sotto una molteplicità di sistemi operativi: OSX Server, AppleShareserver,Windows Server, *niX, BSD e altri ancora.

Linux fornisce supporto completo per le reti AppleTalk tramite una suitechiamata Netatalk. Netatalk è l'implementazione a livello kernel dell'Ap-pleTalk Protocol Suite, derivata da sistemi BSD. Include il supporto perl'instradamento AppleTalk, la condivisione di �lesystem Unix e AFS suAFP (Apple �lling protocol), la condivisione di stampanti Unix e l'acces-so a stampanti AppleTalk tramite PAP, tutti concetti che saranno descrittisucessivamente nel dettaglio.

2.2 AppleTalk e lo standard ISO/OSI

In questa sezione verrà fornita una breve descrizione dei componeti del pro-tocollo AppleTalk. L'architettura AppleTalk consiste in un certo numero

39

CAPITOLO 2. NETATALK 40

Figura 2.1: AppleTalk Protocol Stack nel modello ISO/OSI

di protocolli sistemati sui vari livelli dello standard ISO/OSI come si puònotare in �gura 2.1 e 2.2. I protocolli sono stati sviluppati come una seriedi regole, e sono implementati in maniera di�erente a seconda della speci�capiattaforma. Di seguito si da una descrizione dei vari protocolli AppleTalksuddividendoli in base al livello ISO/OSI di appartenenza.

Presentation/Application Layer I livelli di presentazione/applicazioneassumono che una connessione host-to-host si sia già instaurata e sipreoccupa della sintassi utilizzata per il trasferimento dei dati. Nelmodello ISO/OSI AFP implementa sia livello di presentazione che illivello applicativo.

AFP Il protocooloApple Filling Protocol permette ad una Worksta-tion presente su una AppleTalk network di accedere ai �le presentisu un Server AppleShare. Grazie ad AFP i �le presenti sul discodi un server remoto appaiono alle applicazioni e agli utenti comese fossero sul disco locale. Come si può notare in �gura 2.3 unprogramma in esecuzione locale su di una workstation esegue op-erazioni sui �le usando i comandi nativi del �lesystem. TramiteAFP è possibile usare gli stessi comandi del �lesystem nativo an-che per modi�care risorse residenti su server remoti. Sempre in�gura 2.3, si nota che un programma in esecuzione invia dei co-mandi al �lesystem nativo del sistema. Una struttura dati memo-rizzata in memoria centrale indica se le porzioni di �lesystem cheinteressano le operazioni sono locali o residenti su di un server re-moto, nel secondo caso le richieste vengono inoltrate ad un AFPtranslator che le traduce in richieste AFP e le inoltra in remoto asua volta. Le eventuali implementazioni di AFP in ascolto sul no-


Figura 2.2: AppleTalk Protocol Stack

do remoto devono essere capaci di tradurre richieste ai �le systemnativi in richieste AFP. L'implementazione del protocollo AFP ècomposta essenzialmente da:

1. Struttura di �lesystem, che è composta da risorse (�le server,directory, �le) raggiungibili attraverso la rete.

2. Comandi AFP tramite i quali il computer locale manipola lastruttura del �le system remoto.

3. Algoritmi associati con i comandi che speci�cano la azionieseguite dai comandi.

4. Un sistema di autenticazione a livello utente.

Un �le server è generalmente un computer con una grande capac-ità di memorizzazione utilizzato per condividere risorse sulla rete.Esso è identi�cato da un nome univoco e da altri parametri essen-ziali tra cui : desrizione, numero dei volumi contenuti, versionedel protocollo AFP utilizzato. Un volume è una condivisione resadisponibile sulla rete AppleTalk tramite un �leserver AFP. Cias-cun �le server può condividere più di un volume, abbinando aciascuno di essi determinati parametri tra cui: attributi del Vol-ume (nome del volume, possibilità di memorizzare nome utentee password per limitare l'accesso alla risorse, data di creazione,data di ultima modi�ca).

Il protocollo AFP al contrario dei altri protocolli di rete comeSMB o NFS si riferisce principalmente alle condivisioni (�le edirectory) tramite un identi�cativo ID e non tramite un percorso.Esistono principalmente due tipi di volumi implementati da AFP:


Figura 2.3: Struttura di una chiamata AFP

Fixed Directory ID La struttura gerarchica di questo tipo divolume è composta da directory e sottodirectory, ciascunadelle quali contiene un identi�cativo univoco all'interno delvolume. L'ID viene assegnato alla creazione della directorystessa. Anche se la directory viene cancellata l'ID che le erastato associato rimane non disponibile.

Variable Directory ID Anche questa struttura gerarchica mantieneun univocità di ID all'interno del volume associato ad una di-rectory ma al contratrio del caso precedente l'ID è creatoquando il server AFP manda un comando FPOpenDir (peraccedere alla directory). L'ID viene cancellato quando vieneeseguito un comando FPCloseDir, in seguito al quale l'id ènuovamente disponibile per altre directory. Il Variabale Di-recory Id non è più utilizzato e non è supportato dalle ultimeversioni del protocollo AFP.

Il Volume Catalog, di cui è fornito un esempio in �g 2.4, serveper associare a ciascuna entità di un volume (�le o directory)l'identi�cativo univoco corrispondente. La struttura di un VolumeCatalog deve rispettare le seguenti regole:

• i nodi terminali di una struttura ad albero possono esseredirectory vuote o �le.

• i nodi interni possono essere solo directory, le quali instauranorelazioni di parentela con altri nodi (ad esempio Parent of,O�spring of, ecc...).

All'interno di una struttura di Volume Catalog, anche il nomeCNode (Catalog Node: nome del nodo all'interno del catalogo)identi�ca univocamente il �le o la directory che interessa.


Figura 2.4: Struttura Volume Catalog

Con l'introduzione della versione 3 dell' AFProtocol ora tutte leversione dei recenti sistemi operativo Apple sono in grado di ri-conoscere i caratteri UNICODE codi�cati nel formato UTF8 perquel che riguarda i nomi dei �le1. Per compatibilità con le versionipassate di Mac OS Netatalk supporta anche i vecchi tipi di for-mato carattere tra cui il più di�uso, utilizzato nella maggioranzadei paesi occidentali è il MAC_ROMAN. Per e�ettuare ciascunaoperazione sui CNode ad essi deve essere associato un percorso(chiamato pathname) per poterli raggiungere. A ciascuna en-tità del Catalog Volume possono essere associati più pathname,poichè dipendono dal punto iniziale di partenza. Per ottenerequesto risultato AFP utlizza la struttura visibile in �gura 2.5. Ilpathname associato a ciscuna entità è una stringa Pascal dove neiprimi byte è indicata la lunghezza totale della stringa stessa.

Session Layer Il livello di sessione fornisce un'interfaccia per l'accesso allivello di trasporto sottostante. Il livello di sessione si preoccupa distabilire una connessione (detta sessione) sulla quale si basa il dialogo

1UTF8 è un sistema di encoding dei caratteri Unicode. UTF8 associa a ciascun carat-tere unicode un insieme (da 1 a 4) di ottetti di caratteri. Per maggiori informazioni visitare[23]


Figura 2.5: CNode

tra due applicazioni. Le principali funzioni fornite dal livello di sessionesono controllo di �usso, �ssaggio di punti di recupero sincronizzazioneper veri�ca e recovery di �le transfer. I protocolli Apple Talk situatial livello di sessione sono:

ZIP The Zone Information Protocol. AppleTalk Networking è basatosul concetto di zona, la quale indica un area logica che includegruppi di utenti e risorse. Una zona può estendersi attraverso retimultiple (piu network possono formare un unica zona). I routerseparano le zone e un insieme di zone è chiamato internet 2. Lezone rendono più semplice l'individuazione da parte dell'utentedei servizi disponibili. Ad esempio un certo utente piuttosto chevisulizzare tutti gli utenti o le risorse di una rete può visualizzaresolo quelle della zona di appartenenza. Il concetto di zona è simileal concetto di Workgroup introdotto da Microsoft. Tutti gli hostcollegati a reti AppleTalk utilizzano un indirizzo composto da 2parti: Network Number e Node Number.

Zip Protocol: fornisce alle applicazioni e ai processi accessi allezone identi�candole in base ai nomi. Le principali tipologie diframe ZIP sono:

zonename query / reply: Richiede / fornisce il nome di zonaassociato ad un dato numero di rete.

zonelist query / reply: Richiede o fornisce l'enlenco completodella lista delle zone attive e raggiungibili.

get zone reqst/reply: Richiede / fornisce l'identi�cativo asso-ciato alla zona corrente

take down / bring up zone: Elimina o inserisce una zona al-l'interno della zone list.

All'interno dei frame ZIP vengono utilizzati i seguenti parametriprincipali:

Number: numero della rete da utilizzare in frame zonelist query/ reply

Zone Name: nome associato alla zona

Default Zone: nome della zona corrente.2Durante tutto il capitolo con il termine internet verrà indicato un insieme di zone,

non la rete geogra�ca mondiale.


Take down / Bring up zone: elimina o inserisce una zona al-l'interno della zone list l'elenco delle zone attive.

ASP AppleTalk Session Protocol imposta e mantiene una sessione trauna workstation e il server. ASP è un protocollo asimmetrico nelquale ad un lato della conversazione il client ASP della worksta-tion inizia la comunicazione che verrà sfruttata dalle applicazionidi livello superiore. ASP fornisce anche un meccanismo tramiteil quale il server può mandare un messaggio alle workstation (peresempio in fase di connessione al server o spegnimento di quest'ul-timo). ASP è usato da AFP per permettere ad un utente di ma-nipolare i �le presenti sul �le server. I principali frame utilizzatida ASP sono:

open / close session request: richiesta di apertura e chiusuradi una sessione ASP;

command call request / reply: chiamata ad / ripsosta da unprotocollo di livello superiore;

status request / server status reply: richiesta / risposta sul-lo stato del server;

take down / bring up zone: elimina o inserisce una zona al-l'interno della zone list ;

write continue req: Cominicia o continua il trasferimeto per lascrittura dei dati;

write continue reply: conferma la possibilità di continuare oiniziare a scrivere dati.

All'interno dei frame sopra indicati sono utilizzati i seguenti parametri

Session ID: codice utilizzato per identi�care sessione;Sequence Number: utilizzato dai comandi write continue per

mantenre ordine dei dati;Server session socket: l'identi�cativo della Socket usata du-

rante la sessione;Versione Number: numero di versione ASP correntemente in

uso;Bu�er Size : massima direzione in byte del bu�er in uso;Write continue reply: conferma la possibilità di continuare o

iniziare a scrivere dati.

ADSP AppleTalk Data Stream Protocol (ADSP) è un protocollo connection-oriented tramite i quali i programmi che fanno uso di socket pos-sono scambiare dati. Oltre ad essere connection oriented gestisce il�ow control e controlla l'ordine dei dati ricevuti. ADSP è un pro-tocollo simmetrico, i socket client ai lati della connessione possonoavere uguale controllo sui dati scambiati (al contrario di ASP)Alcuni dei frame ADSP sono i seguenti:


acknowledge/probe: fornisce acknowledge per i dati inviati olo richiede;

open / close connect reqst: richiede l'inizio o la �ne di unasessione ADSP;

retransmit advise: chiede di reinviare i dati.

I principali parametri contenuti nei frame ASP sono:

Source Connection Id: codice utilizzato per identi�care il mit-tente di una connessione;

Destination Connection Id: codice utilizzato per identi�careil destinatario di una connessione;

Send Sequence Number: numero di sequenza utilizzato per lostream di dati in uscita;

Receive Sequence Number: numero di sequenza utilizzato perlo stream di dati in ingresso;

Version: numero di versione in uso.

Transport Level Il livello di trasporto isola alcuni degli aspetti �sici efunzionali tipici di una rete a pacchetti dai tre livelli sovrastanti. Sioccupa di una gestione della connessione end-to-end, preoccupandosianche della gestione della avvenuta ricezione dei dati rispettandonel'ordine. Il livello di trasporto implementa quindi una consegna af-�dabile dei dati implementando meccanismi per l'identi�cazione deglieventuali pacchetti persi e fornendo un meccanismo di bu�erizzazionee ritrasmissione. Appletalk fornisce le seguenti implementazioni perquesto livello:

Name Binding Protocol NBP fornisce a processi e applicazioni unsistema per mappare i nomi delle risorse utilizzabili dalle personecon numeri utilizzati dai computer. Quando un'applicazione èavviata ad essa viene associato un nome, che viene utilizzato daaltre applicazioni per rintracciarla. Quando l'applicazione termi-na viene cancellata l'entry corrsipondente all'associazione nomeapplicazione. Tutte le applicazioni e i processi che usano una reteAppleTalk fanno anche uso di NBP per rendere disponibili sullainternet AppleTalk i servizi o�erti. Un applicazione o un processopuò utilizzare NBP per:

• registrare se stesso con NBP, associando un nome compostoda 3 parti con la socket corrispondente;

• controllare una nuova entry NBP corrispondente ad una nuo-va applicazione;

• rimuovere la propria entry dalla tabella NBP quando non laritiene più util.


Routing Table Maintenance RTMP serve per memorizzare le in-formazioni sul routing necessarie per le internet AppleTalk . RTMPcomunica i numeri di network conosciuti e dati riguardanti l'acces-sibilità, nonchè le vie per raggiungere le varie zone interconnesse.L'implementazione RTMP su di un AppleTalk router mantieneuna tabella, chiamata routing table, che speci�ca il più brevepercorso possibile per raggiungere una rete.

AppleTalk Transaction Protocol ATP permette ad una socket ditrasmettere una richiesta di esecuzione di una determinata oper-azione ad un'altra socket e di riceverne la relativa risposta. ATPfornisce un a�dabile sistema di consegna di pacchetti gestendole ritrasmissioni di eventuali pacchetti persi e garantendo la con-servazione della giusta sequenza di messaggi. Il protocollo ATPpermette di utilizzare i tre seguenti tipi di frame:

request richiesta di dati;

reply in risposta alla request;

release indica la �ne della transazione.

AppleTalk Echo Protocol AEP esiste in ogni nodo come processoclienti che sfrutta il protocollo DDP (si veda nel seguito). Il pro-cesso in questione chiamato AEP Echoer, usa una socket specialeper l'ascolto dei pacchetti trasmessi dalle socket client sugli altrinodi della rete. Quando riceve un pacchetto, l'AEP Echoer loritrasmette direttamente al mittente. I pacchetti AEP possonoessere utilizzati per testare se un nodo è raggiungibile e qual'èla distanza che bisogna coprire (rilevata in numero di hop daattraversare).

Network layer Il Livello di rete speci�ca l'instradamento dei pacchetti datitra i nodi e gestisce le comunicazioni tra reti di�erenti (internetwork-ing). A livello di rete la suite AppleTalk implemente il protocollo DDPe AARP, come di seguito spiegato:

DDP Il Datagram Delivery Protocol è un protocollo connectionlessche fornisce un servizio di tipo best-e�ort. Questo signi�ca cheil protocollo DDP non include supporto per assicurare che tutti ipacchetti siano e�etivamente arrivati a destinazione e nella giustasequenza. Di questo si occupano eventualmente i protocolli dilivello superiore. La rete AppleTalk può funzionare con vari tipidi collegamenti �sici di�erenti:

LocalTalk e è disponibile sui calcolatori Machintosh più vec-chi. Per e�ettuare un collegamento LocalTalk si usa la por-ta stampante del Macintosh. LocalTalk è una connessionerelativamente lenta (230 Kbits/s) ed ormai in disuso.


Figura 2.6: Struttura Frame AARP

TokenTalk AppleTalk sul link �sico TockenRing. Siccome nes-sun Mac è dotato di default delle interfacce necessaria per us-are questo tipo di connessione, TokenTalk si usa solo in casispeciali: per esempio per collegare i Mac ai vecchi calcolatoriIBM, che fanno spesso uso della rete TokenRing.

EtherTalk é l'implemetazione della rete Netatalk su link �si-co ethernet. questo tipologia è sicuramente la più di�usa ela più utilizzata al giorno d'oggi grazie a caratteristiche dia�dabilità e del costo limitato dei supporti �sici.

AARP AppleTalk Address Resolution Protocol è usato per map-pare l'indirizzo dei nodi utilizzato dal protocollo DDP e l'ind-irizzo del livello data link sottostante che fornisce la connet-tività.La struttura del pacchetto Arp è, come indicato in �gura 2.6,composta da:

Hardware type: Identi�catore per il tipo di data-link;

Protocol Type: Identi�catore per il tipo di protocollo;

Hardware Address Lenght: Lunghezza in byte del campoHArdware Address;

Protocol Address Lenght: Lunghezza in byte del campoProtocol Address;

Function: Indica il tipo di funzione del pacchetto AARP: 1richiesta, 2 risposta, 3 test.

Data-Link and Physical Layers: Questi due livelli forniscono la connet-tività. Questi due livelli sono composti dal mezzo trasmissivo utilizzato(doppino, cavo coassiale), dalle periferiche usate per interfacciare i macal mezzo trasmissivo, dai driver per pilotare le periferiche.


2.2.1 Una implementazione del protocollo Appletalk

Linux fornisce supporto completo per le reti AppleTalk. Netatalk è l'imple-mentazione a livello kernel dell'AppleTalk Protocol Suite, derivata da siste-mi BSD. Include il supporto per l'instradamento AppleTalk, la condivisionedi �lesystem Unix e AFS su AFP (Apple �lling protocol), la condivisionedi stampanti Unix e l'accesso a stampanti AppleTalk tramite PAP, tutticoncetti che saranno descritti sucessivamente nel dettaglio.

Fin dalla versione di Mac OS 8.5 Apple fornisce una completa implemen-tazione del protocollo di trasporto Tcp/Ip. Unita all'implementazione delTcp/Ip vi è la modi�ca del protocollo AFP (Apple Filling Protocol) che oraè incapsulabile all'interno di pacchetti Tcp. Mediante l'utilizzo di Netatalksi può integrare il �lesystem Linux all'interno dei sistemi Mac. Con Netatalksi possono addirittura eseguire processi di stampa sulle stampanti Linux econdividere altre risorse.

Netatalk è sofware open-source e consente di trasformare una macchina*niX in un potente ed a�dabile �le server Linux per reti Machintosh. Ilprogetto in origine era sviluppato da un gruppo di ricerca dell'universita delMichigan [25], dopo un periodo di inattività è diventato un prodotto open-source sviluppato da volontari [22]. Usando i servizi di �le server Netatalk2.0 compatibile con AFP 3.1 (l'ultima versione del protocollo di trasportoMacintosh) si ottengono velocità di trasferimento molto maggiori compara-te con l'utilizzo su Mac OS di trasferimenti SMB/NFS[21]. Inoltre Netatalkfornisce supporto per trasferimenti con protocolli AFP compatibili anche convecchie versioni di Mac OS (ad es 8 e 9) i quali non incorporano gli strumentiper l'accesso a reti SMB. Con Netatalk è possibile accedere a stampanti chesupportano il protocollo AppleTalk. Dalla versione 2.0, Netatalk è compati-bile con CUPS il sistema di stampa più utilizzato in ambito *niX. Netatalkpuò anche essere utilizzato come AppleTalk router per suddividere la reteMac in di�erenti zone.

2.3 Compilazione e installazione di Netatalk

In questo paragrafo viene descritta e analizzata la procedura antecedentel'utilizzo di Netatalk. Il pacchetto software Netatalk ha bisogno di libreriesoftware aggiuntive per essere compilato e installato correttamente. Netatalkè utilizzabile sotto varie versioni di sistemi operativi *niX, FreeBsd e Solaris.

La release più recente di Netatalk è la 2.0.1. Questa versione è disponibilesolo sotto forma di sorgenti da conpilare prelevabili da [20]. La versione piùaggiornata disponibile sotto forma di sorgenti per la distribuzione considerata(Fedora core 2) è la 1.6.4. Netatalk è utilizzabile con molti sistemi operativi*niX, FreeBsd e Solaris.

Gcc Per la compilazione di Netatalk è necessario gcc versione 2.7.95 o su-


periori. Per essere compilato con il supporto per AFP 3.1 deve essereattivato sul sitema il supporto per �le di dimensioni maggiori ai 2 Gb.

Berkley Db Berkley Db è un toolkit, realizzato da Sleepycat Software [24]che fornisce agli sviluppatori di software un supporto veloce robustoscalabile per la gestione dei dati. Viene attualmente utilizzato da gran-di realtà come Cisco System, Motorola, Alcatel, Sendmail Inc. BerkleyDb è un prodotto freeware e ope-source ma contiene alcune particolaricondizioni per quanto riguarda soluzioni a pagamento e closed-source.Berkley Db è de�nito embedded poichè è collegato direttamente all'ap-plicazione e lavora nel suo stesso spazio di memoria (non necessita dimeccaniscmi IPC Inter-Process Communications per la gestione dellecomunicazioni tra processi). Può esere collegato ad una applicazionestandalone o a più applicazioni che cooperano. Caratteristica moltoimportante per la cooperazione con Netalk, Berkley Db ha un ottimagestione della concurrency (gestisce l'accesso simultaneo ai dati da piùapplicazioni contemporaneamente).

OpenSSL questo software è opzionale al funzionamento di Netatalk ma èindispensabile per inviare lungo la rete password criptate. OpenSSLpermette di implementare il protocollo SSL V2/V3 (Secure SocketsLayer) e il protocollo TLS V1 (Transport Layer Security) e consistein un insieme di librerie per uso generale utilizzabili da terzi program-mi (come ad esempio Netatalk, Apache). E' un progetto interamentesviluppato da volontari e si basa sulle librerie SSLeay [26] sviluppateda Eric A. Young e Tim J. Hudson.

OpenSlp Slp (Service Location Protocol) è un protocollo sviluppato origi-nalmente dall' IETF 3 che fornisce un supporto alle applicazioni di reteper la scoperta dell'esistenza e della localizzazione e la con�gurazionedi eventuali servizi presenti su una medesima rete. Esistono altri proto-colli di localizzazione su rete (si pensi ad esempio al protocollo SMB)ma prima dell'avvento di Slp nessun protocollo di localizzazione fustandardizzato da IETF. Poichè non è un protocollo proprietario haavuto grande svilupo in ambiente *niX [27].

Dopo aver installato e con�gurato i software sopracitati è necessarioprocedere alla compilazione dei sorgenti.

2.4 Con�gurazione di Netatalk

In questa sezione verrà analizzato il comportamento dei vari componentidella suite Netatalk, utilizzando inoltre un esempio di con�gurazione.

3La Internet Engineering Task Force è una comunità aperta di tecnici, specialistie ricercatori interessati all'evoluzione tecnica e tecnologica di Internet.


Figura 2.7: AppleTalk Protocol Stack

I �le di con�gurazione di Netatalk si trovano solitamente nel percorso/usr/local/etc/Netatalk I demoni del programma sono molteplici e aciascuno di essi è assegnata una funzione speci�ca:

atalkd: implementa RTMP, NBP, ZIP e AEP;

afpd: fornisce ai Mac un interfaccia verso il �le system unix;

papd: permette alle WorkStation Mac di usare stampanti collegate al server*niX Netatalk;

pap: svolge la funzione complementare a papd, consente alle macchine *niXdi usare le stampanti AppleTalk, può essere utilizzato in modalitàstand-alone o come �ltro per CUPS o lpr.

Il protocollo DDP è invece implementato nel Kernel *niX come si può notarein �g2.7. I protocolli ATP e ASP sono implementati come librerie esterne.

2.4.1 Con�gurazione di AppleTalk Routing

Il �le atalkd.conf è utilizzato dal demone atalkd per impostare le interfacceAppleTalk con�gurandone o meno il routing. Per fare in modo che i routerAppleTalk instradino correttamente il tra�co, è necessario che identi�chinocorrettamente ciascun segmento di rete. Nel caso di reti Ethertalk, l'identitàdella rete è stabilita in base ad un Network Number. Per ciascun segmentodi rete collegato al meno un router deve fornire il Network Number cheidenti�ca univocamente il segmento.

Il più semplice metodo per utilizzare Netatalk è non usufruire del serviziodi AppleTalk routing. Questa con�gurazione va usata nel caso in cui siabbia una sola interfaccia di rete. Netatalk è così in grado automaticamentedi impostare l'interfaccia per utilizzare un indirizzo AppleTalk e registrarlosulla rete. Il nome delle zone sono collegati ai segmenti di rete, ma non viè corrispondenza biunivoca. Una zona può infatti estendersi su più networkdi�erenti oltrepassando i router, ad esempio per unire gruppi logici di utenti.


eth0 -dontroute -phase 2 -net 0-65534 -addr 65280.152

Figura 2.8: atalkd.conf: routing disabilitato, 1 interfaccia rete (eth0)



Figura 2.9: atalkd.conf: routing disabilitato, due interfacce di rete (eth0eth1)

AppleTalkRouting disabilitato

Nel caso di interfaccia singola si può decidere se lasciare il �le atalkd.confcompletamente vuoto o utilizzare equivalentemente una sintassi visibile in�gura 2.8 grazie alla quale Netatalk viene impostato per utilizzare l'interfac-cia eth0 e il protocollo fase 2. Il parametro -net 0-65354 indica che non siè in presenza di AppleTalk router. Successivamente viene speci�cato quindiun numero di rete pari a 65280 e un numero di nodo pari a 166 Numeri direte compresi nell'intervallo 65280-65533 e numeri di nodi tra 142-255 fan-no parte dello startup range range all'interno del quale atalkd seleziona unindirizzo se con�gurato in modo automatico senza AppleTalk router.

Nel caso di utilizzo di più interfacce di rete si può utilizzare la con�g-urazione indicata in �gura2.9, con il parametro -dontroute, si informa ildemone atalkd di non utilizzare il routing all'interno della rete AppleTalk.

AppleTalkRouting abilitato

Esistono 3 tipi di�erenti di router AppleTalk, elencati di seguito:

Seed: iene con�gurato con un network number e un nome di zona che iden-ti�ca il segmento di rete a cui è collegato. Ogni segmento su di unaextended network di rete ha almeno un seed-router da cui i client col-legati prendono informazioni. Possono esserci più seed router collegatima non devono contenere informazioni di�erenti in contrasto gli unicon gli altri;

Non seed: è un router con�gurato in modo da ricevere informazioni daun seed router che è connesso alla sua stessa rete. Questo tipo difunzionamento non necessita di alcuna con�gurazione manuale;

Soft-seed: il funzionamento è identico a quello di un Non-Seed Router, oltrea cui si aggiunge la capacità di funzionare come un Seed Router nelcaso in cui il seed router sia momentaneamente fuori uso;


eth0 -seed -phase 2 -net 1-1000 -addr 1000.142

-zone "Printers" -zone "Spoolers"

eth1 -seed -phase 2 -net 1001-2000 -addr 2000.142

-zone "Macs" -zone "Servers"

Figura 2.10: atalkd.conf: seed router

eth0

eth1

Figura 2.11: atalkd.conf: soft-seed router

Il demone atalkd è in grado di funzionare sia come seed che comesoft-seed router. Per impostare atalkd come seed router è necessariofornire i seguenti parametri:

• netrange corrispondente al segmento a cui è associato;

• il suo indirizzo AppleTalk;

• le zone disponibili nel segmento.

Nelle reti AppleTalk i network range non devono sovrapporsi, fortunata-mente atalkd di utilizzare una certa con�gurazione veri�ca prima la possibileesistenza di con�itti sul network. I possibili netrange utilizzabili, in un net-work con router, vanno da 1 a 65279 per far si che non siano sovrapposticon eventuali subnet collegate per le quali è stata usata un impostazioneautomatica di atalkd.Utilizzando il protocollo AppleTalk fase 2 l'indirizzo di rete consiste in unaparte net e una parte corrispondente al nodo (node). Le zone AppleTalk(zone) non hanno nulla a che fare con le reti �siche, servono solo per aiutarel'organizzazione logica delle risorse. Possono esistere network con più zoneal loro interno oppure zone che si estendono su più network. Per con�gu-rare atalkd per l'utilizzo come AppleTalk router bisogna settare le opzionivisibili in �gura 2.10. Se il comando -net viene omesso allora viene utiliz-zato come numero di sottorete quello corrispondente all'indirizzo assegnatoall'interfaccia del server Netatalk. L'opzione -zone può apparire più di unavolta su una stessa riga poichè ad un determinato segmento possono essereassociate più zone.

In �gura 2.11 è presente una semplice esempio di atalkd.conf utilizzabileper con�gurare il demone associato come soft-seed router supponendo chesia presente un seed-router che fornisca le informazioni autoritative per quelsegmento di rete.


"Server Netatalk" -ipaddr 192.168.1.13 -loginmesg "Welcome to

Netatalk Server"

Figura 2.12: Esempio di afpd.conf

~

/public "Cartella pubblica" codepage:MAC_ROMAN

Figura 2.13: AppleVolumes.Default: condivisione di 2 Volumi (home, public)

2.4.2 Con�gurazione di un File Server

AFP è il protocollo utilizzato dai Machintosh per �le service attraverso retiAppleTalk.

afpd.conf

afpd.conf è il �le usato per determinare il comportamento dei �le-servervirtuali gestititi da Netatalk. Gli utenti usati nelle sessioni di AppleTalknetworking coincidono con gli utenti del sistema *niX.Nell'esempio di �gura 2.12 il �le afpd.conf è con�gurato per attivare un unico�le server dal nome �Server Netatalk�, indirizzo ip 192.168.1.13 e messaggiodi benvenuto indicato con la stringa -loginmesg

AppleVolumes.default

Questo �le viene utilizzato per de�nire le share che di default vengono au-tomaticamente mostrate a tutti gli utenti. Per limitare l'accesso ad alcuneshare agli utenti si possono utilizzare i �ag deny e allow. Nell'esempioriportato in �gura 2.13 vengono attivati due Vuolumi:

� Corrisponde alla condivisione delle Home degli utenti, è l'impostazioneprede�nita del server Netatalk conclusa l'installazione.

/public La seconda condivisione indica una share pubblica corrispondenteal mount point /public sul server Netatalk identi�cata dalla stringaCartella Pubblica. Per questa cartella viene utilizzata il formato carat-teri

CNode ID backends

Come già visto il funzionamento del protocollo AFP è basato sulla strut-tura del Catalog Volume e degli ID univoci assegnati alle risorse contenutenel volume. Per consentire una corretta associazione tra gli ID utilizza-ti da AFP e gli elementi del �lesystem *niX Netatalk utilizza una struttura


database. Le strutture database che è possibile utilizzare sono speci�cate nel�le AppleVolumes.default. Il backend più utilizzato, speci�cato con l'opzionecnidscheme:cdb nel �le AppleVolumes.default è concurrent database basatosulle librerie Berkley Db fornite da Sleepycat [24]. Il database viene memo-rizzato nei �le .AppleDb di ogni cartella del Volume AFP. Lavorare con undatabase comporta qualche complicazione, ad esempio non è possibile fer-mare i processi Netatalk improvvisamente poichè si rischia di corrompere ildatabase BerkleyDb.

Autenticazione tramite protocollo AFP

Apple ha scelto per il protocollo AFP un modello fessibile di autenticazionechiamato User Autentication Modules (UAM). Un client AFP inizialmentesi connette ad un server il quale fornisce una lista dei moduli UAM disponi-bili scegliendo tra questi quello con caratteristiche di sicurezza maggiori. Iprincipali metodi di autenticazione UAM sono:

No User Autenth E' utilizzato dagli utenti che eseguono login come ospitisulla macchina.

ClearText Password La coppia username-password è inviata lungo il net-work sotto forma di stringa non cifrata. Il parametro UserAuthInfoutilizzato da AFP consiste in un username (una stringa di massimo255 caratteri) e una password (di massimo 8 byte). La comparazionedello username è case-insensitive, la password è confrontata in modocase-sensitive. Se esiste un utente corrispondente a quello inviato nellastringa UserAuthInfo si passa sucessivamente alla comparazione dellapassword. Se qualcosa non funziona (utente non esistente o passworderrata) nel processo di autenticazione viene inviato un codice di erroreal client.

Random Number Exchange E' utilizzato in caso di rete non sicura doveè possibile uno sni�ng delle password. Con questa tecnica il processodi autenticazione è suddiviso in più fasi, come prima cosa il clientinvia al server il nome utente (inviato in caratteri non criptati lungo ilnetwork). Nel caso in cui l'username non sia valido il server rispondecon un messaggio di errore. Se l'username inviato esiste nel databasedel server allora il processo di autenticazione procede: il server generae invia un numero random a 8 byte e lo invia al client. Sia il client cheil server utilizzano il protocollo DES4. Il testo cifrato viene costruitosia sul client che sul server. Il client invia al server la frase cifrata

4Data Encryption Standard: sviluppato inizialmente nel 1977 è un algoritmo di crit-togra�a che si di una chiave di 56 byte (in questo caso la password dell'utente) che assiemeal testo in chiaro (64 bit ovvero 8 byte il numero random generato) forniscono un testocifrato a 8 byte anch'esso [29].


e sucessivamente il server la confronta con quella costruita. Se le duefrasi cifrate corrispondono l'utente ha guadagnato accesso al �le server.In caso contrario viene ritornato un messaggio di errore.

2 Random Number Exchange Simile al precedente con l'inclusione diun secondo numero random di 8 byte per l'autenticazione del server daparte del client. Entrami i metodi Random Exchange non o�rono altilivelli di sicurezza a causa dell'utilizzo dell'algoritmo DES.

Di�e-Hellman Exchange E' un'implementazione del Di�e-Hellman KeyAgreement Protocol using the SSLeay/OpenSSL [30] il cui nome UAMè DHCAST128. E' più robusto dei precendenti sistemi di crittogra�arispetto ad attacchi di forza bruta, ma non è indenne da attacchi deltipo Man In the Middle, il client infatti non ha possibilità di veri�carel'autenticità del server. Tramite DHX sia il client che il server generanoun numero Ra e Rb utilizzati come chiavi private. Entrambe le partiusano il modulus exponentation per derivare le chiavi pubbliche (Ma eMb) che vengono sucessivamente scambiate. Sucessivamente il clientutilizzando Ra e Mb crea una chiave si sessione k, anche il server a suavolta usando Ma e Rb crea una chiave di sessione k identica. La faseseguente è detta di veri�ca della chiave k, ciascun processo (client eserver) crea un numero random (chiamato nonce) lo codi�ca utilizzan-do come chiave k, e lo invia all'altro processo. Entrambi modi�canoil valore scambiato con un algoritmo noto (per esempio incrementan-done il valore) e riscambiano i valori per veri�care se tutto è avvenutocorrettamente.

I metodi di autenticazione elencati �nora sono stati creati dagli sviluppatoriApple. Esistono altri possibili metodi di autenticazioni creati da sviluppatoridi terze parti tra i quali spiccano:

PGPuam 1.0 UAM basato su algoritmo PGP. Per poter essere utilizatocon Netatalk bisogna compilare i sorgenti con opzione enable-pgp-uam[28].

Kerberos IV - AFS Kerberos Consente l'utilizzo di autenticazione Ker-beros versione 4. Per poterlo utilizzare bisogna compilare netatalk conl'opzione �enable-krb4-uam

Per scegliere il protocollo di autenticazione supportato dal server Ne-tatalk è necessario utilizzare l'opzione AFPD_UAMLIST presente all'interno del�le netatalk.conf. Per quello che riguarda la scelta del protocollo di auten-ticazione utilizzato si dovrebbe far riferimento alle seguenti considerazioni:

1. Evitare No User Authent, poichè può consentire un accesso accidentalee non autorizzato alle risorse. Per avere share pubbliche utilizzare iparametri di accesso con�gurabili in AppleVolumes.default.


2. Il metodo ClearTxt Passwrd non è indicato in quanto vi è possibilitàdi sni�ng dei parametri per autenticazione al server.

3. Randonum exchange e il suo derivato vanno evitati poichè utilizzano ilprotocollo DES e chiavi a soli 56 bit. Inoltre non è possibile integrarequesta autenticazione all'interno del sistema di autenticazione *niX(sia /etc/shadow sia PAM ), è necessario memorizzare le password inchiaro sul server e gestirle tramite il comando afppasswod.

4. DHCAST128 sembra essere attualmente il miglior compromesso poichècombina una forte crittogra�a dei dati ed è integrabile com metodi diautenticazione tipo PAM o /etc/shadow

netatalk.conf

netatalk.conf è il principale �le di con�gurazione della suite Netatalk. Lasua struttura è riportata in �gura 2.14

AFPD_MAX_CLIENTS numero massimo di client che possono accedere contem-poraneamente al server;

ATALK_NAME con�gura il nome del server AppleTalk

ATALK_MAC_CHARSET speci�ca il set di caratteri utilizzato sul Mac;

ATALK_UNIX_CHARSET speci�ca il set di carattere utilizzato sul server;

AFPD_UAMLIST lista degli algoritmi di criptazione utilizzati;

AFPD_GUEST utente *niX corrispondente all'utente guest netatalk;

2.4.3 Principali Utility di Netatalk

In questa sezione vengono analizzate le principali utility che possono essereutlizzate con Netatalk:

aecho AppleTalk Echo Utility. Spedisce pacchetti AppleTalk Echo Protocolagli host della rete. Come opzioni possono essere speci�cate il numerodi pacchetti da inviare e gli host della rete a cui inviarli (indicati conindirizzo Appletalk o nome NBP)

getzones Fornisce un listato contentente i nomi delle zone AppleTalk. Sipuò speci�care se ottenere solo il nome della zona di apparteneza(opzione -m), oppure tutti i nomi delle zone locali (opzione -l).

megatron è usato per convertire �le tra i seguenti formati: BinHex, MacBi-nary, AppleSingle (formati usati da precedenti versioni di MacOS perscambiare dati), AppleDouble (formato usato dall'implementazione ne-tatlk di afpd).


# Appletalk configuration

#Numero massimo di client connessi contemporaneamente

AFPD_MAX_CLIENTS=20

#imposta il nome del server AppleTalk

ATALK_NAME=`echo ${HOSTNAME}|cut -d.-f1`

ATALK_MAC_CHARSET='MAC_ROMAN' ATALK_UNIX_CHARSET='LOCALE'

AFPD_UAMLIST="-U uams_clrtxt.so"

AFPD_GUEST=nobody

# demoni da avviare

ATALKD_RUN=yes

PAPD_RUN=yes

CNID_METAD_RUN=yes

AFPD_RUN=yes

TIMELORD_RUN=no

A2BOOT_RUN=no

# Controlla se far partire i demoni in background

ATALK_BGROUND=no

Figura 2.14: Esempio di netatalk.conf


nbplkup Utility simile all'utility nslookup nelle reti Tcp/Ip. Viene utiliz-zato per visualizzare le entità registrate sul network.

nbprgstr Registra il nome di un elemento nella rete AppleTalk.

nbprgstr Elimina la registrazione associata ad un elemento nella rete Ap-pleTalk. item[Netatalk Webmin Modules]

Webmin

Sul sito u�ciale di Netatalk è disponibile (seppure in versione beta), unplugin per la con�gurazione del server utilizzabile tramite Webmin il notoprogramma per la gestione Web dei sistemi Linux. In �gura .... è pre-sente la schermata principale del plugin Webmin il quale consente di settarenumerose opzioni della suite Netatalk. E' possibile infatti scegliere quali con-divisioni attivare, limitare l'accesso a determinati utenti o gruppi di uten-ti. Tramite l'interfaccia web è anche possibile modi�care le opzioni del �lenetatalk.conf, che altrimenti andrebbe editato manualmente.

Capitolo 3

Cups

3.1 Introduzione

La stampa con i sistemi Unix è sempre stata e�ettuata storicamente con unodei due seguenti sistemi: Berkley Line Printer Daemon (LPD [31]) o AT&TLine Printer System. Questi sistemi vennero sviluppati agli inizi degli annisettanta, per poter inviare stampa testuali alle line printer 1. Sucessivamenteè stato aggiunto il supporto per altri tipi di stampanti.

Nel tempo questi due sistemi sono stati migliorati (LPRng, Palladin,PLP), senza che ne fossero alterate le funzionalità essenziali. Negli ultimidieci anni ci sono stati due progetti che hanno cercato di creare una nuovainterfaccia di stampa standard:

• POSIX Printing Standard sviluppato dall'IEEE (Institute of Elec-trical and Electronical Engineers IEEE-1387.4 ) è ormai abbandonato.Questo progetto de�nisce una serie di tool da linea di comando, uni-tamente ad un interfaccia C, che servono per l'amministrazione dellastampante e dei processi di stampa.

• Internet Printing Protocol (IPP) sviluppato da Internet Engineer-ing Task Force attraverso il PWG (Printer Working Group). IPP for-nisce una serie di estensioni[32] al protocollo HTTP 1.1, allo scopo difornire supporto per la stampa da postazioni remote. CUPS è stato ac-cettato dall'IETF ed è in attesa di essere riconosciuto come standard,è infatti largamente supportato da molti sistemi operativi.

3.1.1 Introduzione a IPP

Nel 1996, Novell si mise in contatto con alcune aziende che avevano dimostra-to initeresse nella ricerca e sviluppo di un protocollo standard per la stampa

1Con il termine line printer viene indicato un tipo di stampante che stampa una lineaper volta, generalmente sono utilizzate in ambienti di lavoro dove è necessario stampare�le formato testuale.

60

CAPITOLO 3. CUPS 61

su Internet. Un primo documento dal nome LDPA (Lightweith DocumentPrinting Application) fu redatto in seguito alla collaborazione tra Xerox eNovell. Contemporaneamente IBM stava sviluppando un progetto simileper la stampa su Internet, basato sul Web e denominato HTPP (HypertextPrinting Protocol). Sucessivamente alla stesura di questi documenti baseper lo sviluppo dei protocolli, venne creato un gruppo di lavoro, chiamatoPWG, al quale parteciparono anche produttori di stampanti e produttoridi print-server. Grazie al lavoro del PWG le linee guida espresse nei docu-menti IBM e Novell Xerox vennero implementate all'interno di un protocollochiamato IPP. Lo scopo principale di questo protocollo è creare uno standardunico per la stampa tramite Internet, minimizzando gli sforzi dei produttoridi hardware, tutt'ora costretti a creare per i loro prodotti driver e softwarenecessari per il supporto dei vari protocolli esistenti. Gli obiettivi (raggiun-ti) dall'ultima versione dell'IPP sono quelli di creare un protocollo a livelloapplicativo che consenta ad utenti e amministatori di:

• scoprire e sfruttare le capacità delle stampanti anche remote;

• inviare e fermare processi di stampa nonchè poter aver informazionisullo stato delle stampanti;

• gestire le transazioni commerciali per la stampa dei documenti

• noti�care automaticamente malfunzionamenti, guasti errori;

• gestire l'accounting delle stampe.

Prima dell'avvento di IPP, lo standard �de facto� per quello che riguarda lastampa via rete poteva essere considerato LPD [31], limitatamente all'utiliz-zo con sistemi operativi *niX. Per compatibilità con i sistemi passati, IPPcontiente alcune funzionalità per la coesistenza con LPD.

Contrariamente a quanto si potrebbe pensare IPP non è un protocolloapplicativo implementato nel livello superiore dello schema TCP/IP, ma èincorporato all'interno di particolari richieste HTTP (utilizzando i metodiPOST e GET ). Il protocollo utilizzato è l'HTTP 1.1, la cui principale dif-ferenza rispetto all'HTTP 1.0 è quella di non utilizzare una connessione TCPseparata per ciascun oggetto richiesto, con un notevole incrememento delleperformance. Per consentire l'incapsulamento di richieste IPP in pacchettiHTTP è stato creato un apposito formato MIME (Multipurpose InternetMail Extensions) denominato application/ipp. Questo formato MIME èutilizzato come contenitore per le richieste e riposte IPP. Grazie sempre all'u-tilizzo di questo formato MIME, è possibile trasportare pacchetti IPP ancheattraverso SMTP.

Un'altro motivo per cui IPP è trasportato in richieste HTTP è facilmenteintuibile se si pensa che molti produttori di stampanti implementano giàil protocollo HTTP all'interno del loro hardware (semplici web server per

CAPITOLO 3. CUPS 62

gestire con�gurazione e stato dei prodotti). Oltre a questa motivazione se nepuò dedurre anche un'altra legata alla di�usione del protocollo HTTP, senzacontare che introdurre un nuovo protocollo applicativo avrebbe aumentatonotevolmente i tempi necessari per la di�usione di IPP.

In seguito all'ampia standardizzazione di IPP, esso è stato implementatosotto una molteplicità di piattaforme, tramite l'ausilio di software di�erenti.IPP è implementano nelle nuove versioni di Windows Server 2003 tramitel'utilizzo di IIS [38] , il popolare Internet Server di Microsoft. Anche altreversioni dei sistemi operativi Microsoft (Windows 2000 e Windows Xp) im-plementano il protocollo IPP, limitandosi però a fornire l'interfaccia client ditale protocollo, o�rendo la possibilità di stampare su stampanti posizionatesu server remoti tramite IPP, ma non consentendo di condividere le stampan-ti ad essi collegati tramite il protocollo stesso. IPP è invece implementato inambienti *niX (Unix, Linux, *Bsd, MacOS, ecc) tramite il pacchetto softwareCUPS.

3.2 Concetti generali

La stampa è sicuramente da considerarsi una delle operazioni più complicatenel mondo IT. In principio, ogni sviluppatore di programmi che volesse esserein grado di stampare, doveva prevedere i driver proprietari per la perifericadi stampa e ciò era ovviamente molto scomodo e molto complicato. Le cosesono migliorate con l'avveto di una serie di linguaggi e tecniche speci�cheper la stampa.

3.2.1 PostScript

Un primo sviluppo verso un linguaggio di stampa generico fu fornito daAdobe con l'invenzione di PostScript. Da un lato i programmatori pote-vano così concentrarsi nella creazione di programmi che dessero in uscita unoutput PostScript compatibile dall'altro i produttori di hardware dovevanoinvece creare Hardware compatibile con il linguaggio PostScript. Con il pas-sare del tempo vennero però sviluppati altri linguaggi di stampa generici,i maggiori concorrenti di PostScript furono PCL (Print Control Language)sviluppato da HP, ESC/P sviluppato da Epson e GDI (Gra�cal Device In-terface) sviluppato da Microsoft. Il linguaggio PostScript resta comunque ilpiù di�uso in ambito *niX. Un esempio di �le PostScript è visualizzato in�gura 3.1, dove i comandi illustrati servono per guidare la stampante nellacreazione delle opportune linee da tracciare.

Si tenga presente che, anche se si usa il linguaggio PostScrpt, le stampantinecessitano di un formato Raster da elaborare. Questo formato può cambiareda stampante a stampante richiedendo piccoli aggiustamenti. Le immagini

CAPITOLO 3. CUPS 63

%!PS % First 2 characters need to be '%!' (magic numbers).

% two boxes % '%' introduces comments. The virtual PS-pen is asked

100 100 moveto % to move to coordinate (100,100), then draw a

0 50 rlineto % relative line 0 units to the right and 50 to the top,

50 0 rlineto % go on with 50 to the right (0 to the top

0 -50 rlineto % now 50 units straight down,

closepath % close the "path",

.7 setgray % switch to 70% gray value for the color to use and

fill % fill the box with this color..

% % First box is finished; next figure

160 100 moveto % is constructed in an analogous way.,

0 60 rlineto % but this time not just with horizontal

45 10 rlineto % and vertical lines, but also with lopsided ones..

0 -40 rlineto % (yes, 20% in PostScript stands for a more

closepath % dark value than 70%).

.2 setgray %

fill % The closing command "showpage" tells

showpage % the printer to eject the page...

Figura 3.1: File PostScript: esempio

visualizzate su una pagina stampata sono immagini Raster 2. Ovviamentetipi di stampanti di�erenti necessitano di formati raster in ingresso di�erentiper produrre il medesimo output, si pensi alle stampanti ink-jet le qualipossono avere da 3 a 6 ugelli di stampa.

3.2.2 RIP

I processi RIP (Raster Imaging Process) servono per convertire i �le PostScriptin appositi formati raster compatibili con l'hardware a cui sono dedicati. Sesi utilizzano stampanti PostScript compatibili, il processo RIP è e�ettuatodall'hardware stesso, tramite un chip o tramite un calcolatore dedicato. Nelcaso in cui non si utilizzino però stampanti PostScript compatibili il pro-cesso RIP è e�ettuato mediante software che accetta in ingresso il formatoPostScript e fornisce in uscita un formato raster compatibile con l'hardwarededicato. Non esistono ovviamente dirver PostScript che funzionino bene contutte le stampanti, ma alcuni di essi forniscono risultati eccellenti, miglioridi quelli ottenibili con i driver Windows, si pensi ai driver Gimp-Print. Dallaversione 1.1.15 CUPS non utilizza più un driver Ghostscript al suo internoma fa a�damento su una versione esterna chiamata ESP Ghostscript.

2Un immagine raster è composta da un insieme di pixel ognuno dei quali ha una po-sizione all'interno di una matrice e una serie di opzioni ad esso associato (colori, luminosità,ecc.)[34]

CAPITOLO 3. CUPS 64

3.2.3 Spooler e Demoni di Stampa

Oltre a queste faticose operazioni di RIP, ogni strumento software necessitadi un meccanismo di SPOOLing, che o�re la capacità di gestire e mem-orizzare job di�erenti, utenti di�erenti, �ltri di�erenti e convogliare tuttoordinatamente verso le periferiche di stampa. Lo spooler è gestito da una se-rie di demoni di stampa. I demoni di stampa sono i processi software tramitecui gli utenti sono invece capaci di calcellare, fermare, riavviare i processi distampa.

3.2.4 File PPD

I �le PostScript sono �le di testo semplice, e quindi incapaci di gestire levarie opzioni della stampante. Per sfruttare le potenzialità native di unastampante si ricorre all'utilizzo dei �le PPD, �le di testo che contengonotutte le opzioni disponibili. I �le PPD creati da Adobe sono di fatto di-ventati uno standard aperto grazie anche all'ottima documentazione fornita.Generalmente i driver della stampante caricano i �le PPD (di cui è visibleun esempio in �gura 3.2) come un �le di con�gurazione aggiutiva, inserendoin un'opportuna interfaccia gra�ca tutte le opzioni della stampante disponi-bili (duplex, risoluzione, ecc...). Prima dell'avvento di CUPS i �le PPDerano utilizzati soltanto in ambienti Windows, ma ora possono essere uti-lizzati anche in ambiente *niX. I �le PPD possono essere utilizzati anchecon stampanti che non sono PostScript compatibili. Con l'avvento di CUPSinfatti è possibile utilizzare tutte le opzioni disponibili su stampanti nonPostScript, mediante l'uso di �le PPD. Questi non sono generalmente svilu-pati dai produttori hardware, i quali si limitano a produrre driver prorietarispesso compatibili solo con Windows, ma sono sviluppati dal team CUPS eda altri programmatori volontari. Gli archivi più importanti di �le PPD perstampanti non PostScript sono :

• linuxprinting.org (e il pacchetto foomatic, si veda in seguito);

• gimp-print.org di cui si parlerà nel seguito;

• estensione commerciale di CUPS.

3.3 Struttura di CUPS

CUPS (Common Unix Printing System: Sistema Comune di Stampa Unix)fornisce un completo e moderno sistema di stampa per UNIX che può es-sere esteso per supportare nuove stampanti, periferiche e protocolli. CUPSè un prodotto free software sviluppato dalla Easy Software Products [33] erilasciato sotto licenza GNU/GPL e GNU/LGPL (General Public License &Library General Public License). La prima release di CUPS (basata sul pro-tocollo IPP 1.0) venne rilasciata nel settembre 1999, fu seguita da numerose

CAPITOLO 3. CUPS 65

Parametri Principali dei File PPD

Ozione Tipo dato Descrizione

accurate_screens int

color_device int

colorspace ppd_cs_t

contone_only int

num_emulations int numero di emulazioni supportate

emulations ppd_emul_t tipo di emulazioni supportatre dalla stampante

�ip_duplex int 1 = invertire le pagine dispari per stampa duplex

num_fonts int numero di font supportati dalla stampante

fonts char fonts supportati dalla stampante

jcl_begin jcl_ps jcl_end char controlli per il Job Control Language Postscript

landscape int orientazione sfondo -90◦ + 90◦

lang_encoding char * carattere usato per le opzioni

lang_version char * linguaggio usato per le opzioni

language_level 0.894 livello postscript utilizzato (1,2,3)

manual_copies int indica il numero di copie

model_number int modello del driver

patches char * comandi da inviare alla stampante

manufacturer char * creatore del �le ppd

modelname char * nome del modello del �le PPD

nickname char * nickname del �le ppd

product char * altri attributi del diel

shortnickname char * un altro nome eventuale del �le

throughput int numero di pagine al minuto (ppm)

ttrasterizer char *

variable_sizes int

Figura 3.2: Struttura dei �le PPD

CAPITOLO 3. CUPS 66

Figura 3.3: CUPS struttura generale

patch per migliorarne la sicurezza, portabilità e diminuire i big scoperti, manon vennero aggiunte nuove funzionalità. L'ultima versione di CUPS (ver1.1) è basata sul protocollo IPP 1.1 aggiunge numerose funzionalità richi-este dagli utenti �nali. Come molti sistemi di stampa CUPS è strutturatoattorno ad uno scheduler che si occupa di smistare i processi di stampa,fornire informazioni sullo stato della stampante ai programmi locali, remotie agli utenti. In �g 3.3 è mostrata la struttura fondamentale di CUPS.Nelle seguenti sezioni verranno spiegati nel dettaglio i singoli componentidel sistema CUPS.

3.4 Scheduler

Lo scheduler di CUPS è un server HTTP/1.1, che oltre a gestire le richiesteHTTP per il supporto del protocollo IPP, funziona da web server per quel-lo che riguarda la documentazione, il monitoring e l'amministrazione. Loscheduler gestisce anche una lista delle stampanti disponibili su di una LAN,associando i processi di stampa al relativo Backend o Filtro necessario.

3.5 Con�guration File

I �le di con�gurazione sono �le testuali per le impostazioni del server HTTP,la con�gurazione delle stampanti e classi di stampanti, ecc.

3.5.1 Con�gurazione del server HTTP

Il �le cupsd.conf simile ai �le di con�gurazione di Apache [35], de�niscetutti ì controlli per l'accesso alle risorse del server, ed è utilizzato per la con-�gurazione principale dello scheduler. Un esempio di cupsd.conf è visibilein �gura 3.4, i principali parametri di con�gurazione del �le sono i seguenti:

CAPITOLO 3. CUPS 67

• ServerName indica il nome del server CUPS (di default è l'hostnamedel computer su cui CUPS è installato);

• DocumentRoot è il percorso per la documentazione locale di CUPSvisualizzabile tramite interfaccia web;

• PreserveJobHistory consente di conservare una lista dei job e�ettuati;

• PreserveJobFiles permettee di conservare una copia dei job e�et-tuati;

• Printcap speci�ca la posizione del �le printcap utilizzato per compat-ibilità con il sistema di stampa BSD;

• Printcap Format speci�ca il formato del �le printcap;

• ServerBin speci�ca la posizione delle directory dove sono posizionati�ltri e backend di cups;

• ServerRoot speci�ca la posizione dei �le principali di CUPS;

• Port indica la porta su cui è in ascolto il webserver CUPS;

• BrowseProtocol indica il protocollo per il browsing delle stampanti direte;

• BrowseInterval indica la frequenza di aggiornamento delle stampantiin rete tramite browsing.

I restanti parametri di con�gurazione servono per un controllo di accesso alivello utente, alle stampanti condivise o alle classi disponibili.

Il server web con�gurato tramite il �le sopracitato, fornisce una comodainterfaccia utilizzabile tramite browser il cui aspetto è visibile in �gura 3.5.

Nella sezione per l'amminstrazione delle stampanti (�g3.6) e delle classi(�g3.7) è possibile inserire nuove stampanti oppure modi�care le opzioni diquelle già installate. Nella sezione dedicata ai Job (�g3.8), è invece possibilevisualizzare i lavori di stampa e�ettuati e quelli ancora presenti nella codadi spooling.

3.5.2 File di con�gurazione per stampanti

Il �le di con�gurazione per le stampanti è printers.conf. Una porzionedi questo �le è visibile in �gura 3.9. Normalmente questo �le non è editatomanualmente ma è creato tramite lpadmin o l'interfaccia web di CUPS.

Il �le clesses.conf, che viene anch'esso modi�cato da lpadmin o dainterfaccia web, serve per con�gurare le classi di stampanti installate sulsistema. Viene de�nita classe di stampanti un'insieme di stampanti, unastampa inviata ad una classe di stampante viene inoltrata ad una stampantedisponibile secondo l'algoritmo Round Robin.

CAPITOLO 3. CUPS 68

ServerName nomeserver

DocumentRoot /usr/share/doc/cups-1.1.20

PreserveJobHistory Yes

PreserveJobFiles No

Printcap /etc/printcap

PrintcapFormat BSD

ServerBin /usr/lib/cups

ServerRoot /etc/cups

Port 631

Browsing On

BrowseProtocols cups

BrowseInterval 30

<Location /admin>

Order Deny,Allow

Deny From All

Allow From All

</Location>

<Location /printers/hp>

Order Deny,Allow

Deny From All

Allow From 127.0.0.1

AuthType None

Allow from All

</Location>

<Location />

Order Deny,Allow

Deny From All

Allow From All

</Location>

Figura 3.4: Esempio di cupsd.conf

CAPITOLO 3. CUPS 69

Figura 3.5: CUPS: homepage interfaccia web

Figura 3.6: CUPS: sezione stampanti interfaccia web

CAPITOLO 3. CUPS 70

Figura 3.7: CUPS: sezione classi di stampanti

Figura 3.8: CUPS: sezione job di stampa

CAPITOLO 3. CUPS 71

<DefaultPrinter hp>

\Location

DeviceURI usb:/dev/usb/lp0

State Idle

Accepting Yes

JobSheets none none

QuotaPeriod 0

PageLimit 0

KLimit 0

</Printer>

Figura 3.9: Esempio di printers.conf

3.5.3 Tipologie MIME supportate

Le tipologie MIME supportate da sistema CUPS, sono incluse nel �le mime.typesa cui normalmente non vanno apportate modi�che. Utilizzando questo �leCUPS controlla le tipologie mime inviate ai client e ricevute da essi. Spedireuna tipologia mime corretta ai client è utile a�nche essi possano associare il�le handler più opportuno.

3.6 CUPS API

Le CUPS API contengono funzioni utilizzabili nei programmi utente, peraccodare processi di stampa, rilevare le informazioni, accedere alle risorse viaHTTP e IPP. Le librerie CUPS forniscono inoltre un insieme di interfaccescritte in C che permettono di operare con applicazioni, �ltri di stampa,backend e driver per stampanti di CUPS. Di seguito vengono illustrate alcunedelle principali API di CUPS, utilizzate dagli sviluppatori del progetto pergestire semplici processi di stampa.

In �gura 3.10 viene illustrata la funzione cupsPrintFile, utilizzata perstampare singoli �le. I parametri della funzione sono i seguenti:

name è il nome della stamapante o della classe di stampanti a cui inviare iljob di stampa;

filename è il nome del �le da stampare;

title è il nome del job di stampa;

jobid è il valore di ritorno della funzione, un intero indicante il numero deljob oppure 0 nel caso di errore.

In �gura 3.11 viene illustrata la funzione cupsCancelJob utilizzata percancellare i processi di stampa accodati.

CAPITOLO 3. CUPS 72

#include <cups/cups.h>

int jobid;

jobid = cupsPrintFile("name", "filename", "title", 0, NULL);

Figura 3.10: CUPS API: cupsPrintFile

jobid è il umero di job da eliminare, può essere ad esempio il valore diritorno di una precedente cupsPrintFile;

status è un intero indicante lo stato della cancellazione, il suo valore è 1 sel'eliminazione avvenuta 0 se l'eliminazione non ha vuto successo.


int jobid;

int status;

status = cupsCancelJob("name", jobid);

Figura 3.11: CUPS API: cupsGetDest

Alcune API che CUPS fornisce servono per la gestione e il monitoringdelle code di stampa. Tra queste si ricorda cupsGetsDest, rappresentata in�gura 3.12. Questa interfaccia viene utilizzata per ottenere una lista dellestampanti o classi attualmente disponibili, num_dest indica il numero dirisorse disponibili e dest è un puntatore ad una struttura.

Le risorse disponibili (classi o stampanti) sono identi�cate da una strut-tura visibile in �gura 3.13.


int num_dests; cups_dest_t *dests;

num_dests = cupsGetDests(dests);

Figura 3.12: CUPS API: cupsCancelJob

Se qualsiasi API di CUPS indica un errore, il valore esatto del codice dierrore associato può essere ricavato tramite la funzione cupsLastError(),la quale ha come valore di ritorno il codice di errore IPP associato. Spesso

CAPITOLO 3. CUPS 73

typedef struct /**** Destinazione ****/

{

char *name, /* Nome della stampante o della classe */

*instance; /* Local instance name or NULL */

int is_default; /* indica se è classe o stampante di default */

int num_options; /* numero delle opzioni applicabili */

cups_option_t *options; /* puntatore ad una struttura di opzioni */

} cups_dest_t;

Figura 3.13: CUPS API: struttura cups_dest_t

il valore di ritorno di cupsLastError() è utilizzato come valore di input dicupsErrorString() che serve per convertire il codice di errore IPP in unastringa testuale più chiara all'utente, si guardi la �gura 3.14.


int jobid;

if (jobid == 0)

puts(cupsErrorString(cupsLastError()));

Figura 3.14: CUPS API: cupsLastError e cupsErrorString

Le funzioni �n qui illustrate sono utilizzabili per tutte le stampanti chesono con�gurate con CUPS. CUPS fornisce però una serie di funzioni speci-�che per le stampanti Postscript. Queste funzioni servono principalmente perl'accesso e la manipolazione dei �le PPD (Postscript Printer Description),che descrivono i caratteri, la dimensione della carta, la risoluzione e altrecaratteristiche proprie della stampante in uso. I driver di stampa utilizzanoi �le PPD per apprendere le capacità e le caratteristiche delle stampanti.

In �gura 3.15 vengono illustrate le principali funzioni che le CUPS APIconsento di e�etturare su �le PPD.

filename è il nome del �le PPD associato ad una stampante o ad unaclasse di stampanti, indicata dalla stringa name. Tramite ppdOpenFile()

si può aprire il �le PPD desiderato; ppdClose() è utilizzato per liberare lamemoria quando si ha �nito di utilizzare il �le in questione; ppd_file_t

indica la struttura corrispontente ad un �le PPD i cui attributi sono elencatiin �gura 3.2.

CAPITOLO 3. CUPS 74


const char *filename;

filename = cupsGetPPD("name");

ppd_file_t *ppd;

ppd = ppdOpenFile("filename");

ppdClose(ppd);

Figura 3.15: CUPS API: cupsGetPPD() ppdOpenFile() ppdClose()

3.7 Berkeley and System V Commands

I comendi Berkely e System V sono un insieme di strumenti che funzionanoda linea di comando forniti da CUPS che o�rono una completa interfacciaper eseguire print job e veri�care lo stato delle stampanti. Tutte le im-postazioni che possono essere eseguite tramite la comoda interfaccia Webpossono essere e�ettuate mediante l'utilizzo dei comandi shell che CUPSmette a disposizione. Grazie a questa serie di comandi il server di stampaCUPS consente una completa e sicura gestione remote. Di default il webserver CUPS integreato nello scheduler infatti non utilizza connessioni crip-tate, si incorre così nella possiblità di sni�ng dei parametri di accesso alserver.

Per comprendere al meglio il funzionamento delle utility da linea di co-mando fornite con CUPS è necessario capire la struttura delle code di stampasotto *niX. Ogni coda è identi�cata da un nome di massimo 127 caratteri,che può contentere numeri e lettere. Le code di stampa hanno anche unaperiferica associata ad esse (porta parallela, usb, ecc). A ciascuna perifericain CUPS è associato un URI (Uniform Resource Identi�er) simile alle URLutilizzate dai browser. Alla prima porta parallela è associato ad esempiol'identi�cativo: parallel:/dev/lp1.

Sucessivamente verranno elencati alcune delle più comuni utility utiliz-zate con CUPS.

3.7.1 lpstat

lpstat deriva dall'omonimo comando di gestione stampe fornito da SystemV. lpstat visualizza informazioni sulle classi correnti, job di stampa e stam-panti. Se viene invocato senza argomenti, lpstat lista tutti i lavori in codadall'utente.

CAPITOLO 3. CUPS 75

3.7.2 lp status

Questo comando, ereditato dall'omonimo di System V, viene utilizzato perstampare �le su una stampante speci�cata (opzione -d destination). Leopzioni più utilizzate sono:

-n copies imposa il numero di copie;

-q priority imposta priorità processo di stampa;

-P page list imposta le pagine del documento da stampare

3.7.3 lpc status

lpc status è una piccola utility che fornisce un controllo limitato sulle codesi stampa presenti in CUPS. Può essere utilizzato per capire lo stato diuna coda di stampa. lpc adotta una sintassi simile a quella del comandoomonimo implementato dal sistema di stampa Berkely. A causa di unacompatibilità col passato, molte utility con�gurabili per le code installatesotto CUPS non sono disponibili con lpc status, è consigliato l'utilizzo dilpadmin come suo sostituto.

3.7.4 lpq

lpq è derivata dall'omonima utility di Berkeley, dalla quale eredita la sintassi,viene utilizzata per interrogare le code di stampa (se non è speci�cata nessunacoda viene utilizzata quella prede�nita).

3.7.5 lprm e cancel

Utility derivate dalle rispettive omonime di Berkely e System V per la ri-mozione dei job di stampa da una coda.

3.7.6 lpadmin

lpadmin è il comando principale di CUPS, utilizzato per gestire le stampantie le classi di stampanti. La sintassi generale del comando lpadmin è visibilein �gura 3.16 Le opzioni utilizzate sono le seguenti

lpadmin [ -E ] -d destination

lpadmin [ -E ] -p printer option(s)

lpadmin [ -E ] -x destination

Figura 3.16: lpadmin: sintassi generale

-E serve per speci�care se i dati inviarti al server vanno critpati o meno.

CAPITOLO 3. CUPS 76

-d imposta la stampante o classe speci�cata come default per il sistema

-x elimina la stampante o classe speci�cata

3.7.7 cupsaddsmb

Questa utility fornisce un ottimo support per l'integrazione tra CUPS e ilserver Samba. Infatti grazie a questo tool è possibile esportare le stampantiCUPS installate sul sitema in modo che siano visibili sul network SMB. Lasintassi del comando è visibile in �gura 3.17

cupsaddsmb [ -H samba-server ] [ -U samba-user ]

[ -h cups-server ] [ -v ] -a

Figura 3.17: cupsaddsmb: sintassi

Le opzioni utilizzate sono:

-H samba-server server Samba in cui verranno esportate le stampanti;

-U samba-user utente che avrà controllo amministrativo sulle stampanti;

-v utilizza la modalità verbose per visulizzare evenutali problemi nell'es-portazione;

-a esporta tutte le stampanti;

-h speci�ca un server CUPS da utilizzare.

3.7.8 lpinfo

lpinfo mostra tutte le periferiche disponibili o i driver riconosciuti dalsistema CUPS. Le ozpioni del comando sono:

• -l mostra un listato esteso delle periferiche e dei driver disponibili;

• -m mostra i driver per le stampanti disponibili sul sitema;

• -v mostra le stampanti disponibili sul sitema.

3.8 Filters

I �ltri sono programmi che che leggono informazioni dallo standard input ele riversano, modi�cato, sullo standard output. Anche CUPS si avvale di�ltri per la stampa. Tutti i �ltri devono supportare un set comune di opzioniincluso il nome della stampante, job ID, username, job title, numero di copiee opzioni eventuali. Il sistema di �ltering di CUPS è �essisbile e molto

CAPITOLO 3. CUPS 77

potente, ed è creato con una struttura di tipo modulare. Grazie a questasua caratteristica tutti i �ltri di terze parti sono utilizzabili con semplicità, evi è anche la possibilità di creare �ltri personalizzati come ad esempio quelliforniti dai produttori hardware. Il modo più semplice per creare nuovi �ltriè quello di progettarli in modo che accettino in ingresso il formato CUPS-Raster (registrato come formato MIME dalla IANA), e forniscano in uscitail formato raster speci�cio per l'hardware a cui sono destinati. Uno dei �ltripiù importanti da utilizzare con CUPS è foomatic.

3.8.1 foomatic

foomatic naque nel 2000, quando CUPS non era ancora molto conosciutoe supportava solo un centinaio di stampanti, CUPS comprendeva già il �l-tro pstoraster (da PostScript a raster) e aveva un ottimo supporto per lestampanti Postscript grzie all'uso dei �le PPD. L'autore di foomatic avevaun database molto vasto con l'elenco di stampanti a cui associare un op-portuno �le PostSript. La sua idea fu quella di generare �le PPD dal suodatabase di informazioni, e usare questi �le per creare �ltri standard peril funzionamento con CUPS. Grazie a questa idea si riusci ad aumentarenotevolmente il numero di stampanti funzionanti con CUPS, fornendo tuttele opzioni avanzte di CUPS (interfaccia web, classi di stampanti) a tutte lepersone che volevano utilizzare i driver Ghostscript.

3.8.2 pap

Un altro �ltro che può essere utilizzato è pap. Questo compnente della suiteNetatalk o�re la possibilità di installare e gestire tramite CUPS le stampanticon�gurate dal server papd Netatalk. Così facendo si rendono disponibili allarete *niX le stampanti AppleTalk di di�cile utilizzo.

3.9 CUPS Imaging

Queste librerie CUPS forniscono un supporto per il trattamento delle im-magini, come ad esempio impostazione dei livelli di colore, scalatura delleimmagini per la stampa, ecc. La libreira più famosa per il trattamento delleimmagini è sicuramente costituita dai �ltri gimp-print [39].

Gimp-print

Gimp-Print è un insieme di driver per la stampa ad alta qualità utilizz-abile sotto diverse piattaforme: Linux, BSD, Solaris, IRIX, e altri *niX pi-attaforme. In molti casi questi driver hanno più funzioni dei driver standardforniti con le periferiche. L'obiettivo del team di sviluppo di Gimp-Printè ottenere la più alta qualità di stampa disponibilie dalle stampanti. Le

CAPITOLO 3. CUPS 78

libreire Gimp-Print non o�rono solo supporto per la stampa attraverso ilnoto programma di gra�ca, o�rono inoltre plugin utilizzabili con foomatice �ltri di stampa dalle caratteristiche avanzate per CUPS. Normalmente i�ltri Gimp-Print per CUPS non sono inclusi in una intallazione standarddel programma (ad eccezzione dell'installazione di CUPS in Mac OSX). Lecaratteristiche principali del pacchetto sofware Gimp-Print sono:

• supporto per oltre 300 stampanti (Canon,Epson,HP,Lexmark ecc);

• plugin stampa per The GIMP[40];

• driver CUPS avanzato;

• supporto completo di Footmatic, per una gestione sempli�cata deidriver;

• supporto per un ampia scala di regolazioni (luminosità, contrasto,sintonia colori);

• utility per permettere il supporto completo di molte stampanti Epsonee Lexmark (indicazione di livello di inchiostro, carta esaurita, ecc);

• ampia documentazione per sviluppatori e utilizzatori.

3.10 Backends

Backends è un �ltro speciale che invia dati direttamente ad una periferica oad una connessione. CUPS prevede backends per interfacce parallele, seriali,USB, LPD, IPP, JetDirect. Samba (dalla versione 2.0.6 in poi), prevede unottimo backend per poter stampare sulle stampanti *niX da sistemi Win-dows. La con�gurazione di Samba, per poter condividere sulla rete SMB lestampanti installate sotto CUPS, prevede normalmente l'inserimento delleseguenti opzioni in smb.conf visibili in �gura 3.18.

printing=cups

printcap=cups

Figura 3.18: smb.conf: uso delle stampanti CUPS

3.10.1 Samba Backend

In questa sezione verrà analizzato l'utilizzo di Samba come backend perCUPS per consentire ai client Windows di stampare su stampanti CUPS. Pere�ettuare questa condivisioe di risorse, visualizzabile in �gura 3.19, si hannodue possibilità, l'utilizzo dei driver del produttore forniti con la stampante,l'utilizzo dei driver Ghostscript forniti con CUPS.

CAPITOLO 3. CUPS 79

Figura 3.19: stampa di rete tra client server eterogenei

RAW Printing

Installando tramite CUPS la stampante come RAW printer, i client Win-dows vanno impostati per utilizzare i driver u�ciali forniti dal produttorehardware, così facendo si possono sfruttare tutte le potenzialità della stam-pante (es: stampa fronte retro, stampa più di una pagina per foglio, ecc...)fornite dai driver u�ciali. Grazie all'uso combinato di CUPS e Samba, sipuò impostare il �le server di modo che i client che tentano di connettersi aduna stampante ricevano in automatico i driver dal server. Questa funzion-alità è molto comoda e diminuisce il tempo di installazione delle stampantisui client. Nella share [print$] del �le smb.conf di �gura 3.20 vanno in-seriti i driver opportuni per la stampante. In seguito a queste impostazioniil sistema GDI dei client produrra in output un formato Windows EMF(Enhanced Meta File, immagini raster) speci�che per l'hardware a cui sonodestinati. Con questa con�gurazione, il server CUPS viene utilizzato comesemplice server di SPOOLing, ovvero i client forniscono a CUPS dati conun formato già comprensibile per la stampante. CUPS si occupa solo dell'i-noltro dei dati verso la stampante. Questa con�gurazione, non necessita diun grosso dispendio di CPU del server CUPS.

CUPS utilizzato come RIP

Grazie alla capacità di CUPS di utilizzare i �le PPD, si può utilizzare il serverCUPS come software RIP, impostando sui client il driver ADOBE PostScript,eventualmente associandolo al download automatico tramite Samba come

CAPITOLO 3. CUPS 80

[global]

load printers = yes

printing = cups

printcap name = cups

[printers]

comment = All Printers

path = /var/spool/samba

browseable = no

public = yes

guest ok = yes

writable = no

printable = yes

printer admin = root

[print$]

comment = Printer Drivers

path = /etc/samba/drivers

browseable = yes

guest ok = no

read only = yes

write list = root

Figura 3.20: smb.conf: download automatico dei driver e condivisione dellestampanti

CAPITOLO 3. CUPS 81

visto in precedenza. Le stamanti presenti sul server CUPS dovranno essereassciate all'opportuno �tro PPD, sia che esse siano PostScript compatibilio che esse non lo siano. Il drver ADOBE PostScript installato sui clientpermette di convertire l'output del programma che ha inviato una stampain un �le PostScript compatibile, che verrà inviato sul server di Stampa esucessivamente dopo un opportuno RIPing verrà inviato alla stampante. Il�ltro RIP di CUPS è basato sul pacchetto GhostScript. La con�gurazionedi CUPS come sofware RIP consente tre principali vantaggi:

1. i dati gestiti da CUPS e ricevuti dai client Windows sono gestiti uni-formemente mediante l'utilizzo del formato PostScript;

2. tutti i �le di stampa passano da CUPS che può essere utilizzato per ilcontrollo delle stampe (ad esemprio il conteggio).

3. sui client è prevista l'installazione di un driver unico evitando cosìpossibili con�itti e sempli�cando la manutenzione.

Indipendentemente dalle due con�gurazioni sopra citate prima di poterutilizzare le stampanti CUPS nel network Samba è necessario l'utilizzo del co-mando cupsaddsmb. Questo comando copia i �le necessari per l'installazionedelle stampanti sui client nella share [print$].

3.11 Network Printing

Tradizionalmente, la stampa di rete è piuttosto complicata sotto Unix. Unodei principali motivi deriva dal fatto che ciascun produttore ha aggiuntole sue estensioni personali al protocollo LPD. Un'altra problematica legataalla stampa via rete è la di�colta di amministrazione decentralizzata di ognistampante, e la necessità di impostare, su ogni client, le stampanti remoteda utilizzare (operazione, che può richiedere molto tempo in ambienti conun elevato numero di client). Verranno ora anlizzate diverse con�gurazioniche consentono a client CUPS *niX di utilizzare le stampanti presenti nellarete.

Con�gurazione Manuale dei Client

Con il termine client viene indicato un computer che invia lavori di stampa adun altro computer (server) a cui è collegata una stampante. I client possonoessere a loro volta server se comunicano direttamente con una stampante.

Un esempio di con�gurazione manuale può essere quello visualizzatoin �gura 3.21, tramite l'utilizzo di lpadmin, nel quale si prevede l'instal-lazione della coda remota hp sul server di indirizzo ip ipserver. La stessacon�gurazione la si può ottenere utilizzando l'interfaccia Web.

CAPITOLO 3. CUPS 82

lpadmin -p printer -E -v ipp://ipserver/printers/hp

Figura 3.21: lpadmin: impostazione coda remota ipp: sintassi

Con�gurazione di un server unico per la stampa

CUPS può essere con�gurato per funzionare senza un spooler locale in mododa inviare tutti i job verso un server singolo, nel caso in cui questo servernon sia più utilizzabile tutte le stampe sarebbero disabilitate. Normalmenteil server di default è localhost, (il server CUPS in ascolto locale), se si vuoleutilizzare uno spooler remoto bisogna modi�care il �le client.conf (le mod-i�che hanno e�etto su tutto il sistema) oppure il �le /.cupsrc (le modi�cheavranno e�etto solo sugli utenti speci�cati). Le modi�che da e�ettuare ai�le sopraelencati sono visibili in �g 3.22:

ServerName server


dove server è il nome o l'indirizzo ip dello spooler remoto.

Con�gurazione automatica dei client

CUPS fornisce un sistema di �printer browsing�, che permette ai client divedere automaticamente e utilizzare le stampanti di ciascun server sulla LAN.Tramite questa funzionalità, si con�gura il server e i client ottengono unacon�gurazione automatica delle stampanti. Se di desidera utilizzare le stam-panti da parte di client *niX su un server CUPS presente nella stessa subnet,allora non è necessario eseguire alcuna operazione: ciascun client ad inter-valli di 30 secondi verrà avvisato delle evenutali variazioni delle risorse distampa disponibili.

In caso in cui interessi utilizzare la con�gurazione automatica per stam-panti presenti in subnet di�erenti dalla propria bisogna utilizzare il pollingper interrogare i server sulle altre subnet e sucessivamente distribuire le in-formazioni all'interno della subent di appartenenza. Con la con�gurazionedi cupsd.conf in �gura 3.23, da e�ettuarsi su un client della propria sub-net, si istruisce il client in questione ad interrogare tramite BrowsePolling

i due server Server A e Server B e a distribuire tramite BrowseReleay leinfo sulla propria subnet. Gli altri client non necessitano di modi�che al �lecupsd.conf.

CAPITOLO 3. CUPS 83

ServerName server


Elenco delle �gure

1.1 Troughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Response time . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 stack tcp e posizione protocollo smb . . . . . . . . . . . . . . 151.4 Schermata principale ethereal . . . . . . . . . . . . . . . . . . 191.5 Composizione della rete: server Samba, client Windows XP . 201.6 �ag unique e �ag group . . . . . . . . . . . . . . . . . . . . . 211.7 Samba pacchetti 1-23 . . . . . . . . . . . . . . . . . . . . . . . 221.8 smb.conf: Samba con�gurato come Preferred Master . . . . . 231.9 Samba: Pacchetti 26-33 . . . . . . . . . . . . . . . . . . . . . 241.10 Pacchetto 34: dettaglio . . . . . . . . . . . . . . . . . . . . . . 241.11 Samba: dettaglio Pacchetto 38 . . . . . . . . . . . . . . . . . 251.12 Samba: Pacchetti 45 - 53 . . . . . . . . . . . . . . . . . . . . 261.13 Pacchetti 68 - 72 . . . . . . . . . . . . . . . . . . . . . . . . . 261.14 smb.conf: esempio . . . . . . . . . . . . . . . . . . . . . . . . 281.15 smb.conf: uso stampante Windows con client Linux . . . . . 311.16 SWAT homepage . . . . . . . . . . . . . . . . . . . . . . . . . 341.17 SWAT wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.18 Plugin Samba per Webmin . . . . . . . . . . . . . . . . . . . 361.19 Smb4k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1 AppleTalk Protocol Stack nel modello ISO/OSI . . . . . . . . 402.2 AppleTalk Protocol Stack . . . . . . . . . . . . . . . . . . . . 412.3 Struttura di una chiamata AFP . . . . . . . . . . . . . . . . . 422.4 Struttura Volume Catalog . . . . . . . . . . . . . . . . . . . . 432.5 CNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.6 Struttura Frame AARP . . . . . . . . . . . . . . . . . . . . . 482.7 AppleTalk Protocol Stack . . . . . . . . . . . . . . . . . . . . 512.8 atalkd.conf: routing disabilitato, 1 interfaccia rete (eth0) . . 522.9 atalkd.conf: routing disabilitato, due interfacce di rete (eth0

eth1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.10 atalkd.conf: seed router . . . . . . . . . . . . . . . . . . . . 532.11 atalkd.conf: soft-seed router . . . . . . . . . . . . . . . . . . 532.12 Esempio di afpd.conf . . . . . . . . . . . . . . . . . . . . . . 54

84

ELENCO DELLE FIGURE 85

2.13 AppleVolumes.Default: condivisione di 2 Volumi (home, public) 542.14 Esempio di netatalk.conf . . . . . . . . . . . . . . . . . . . 58

3.1 File PostScript: esempio . . . . . . . . . . . . . . . . . . . . . 633.2 Struttura dei �le PPD . . . . . . . . . . . . . . . . . . . . . . 653.3 CUPS struttura generale . . . . . . . . . . . . . . . . . . . . . 663.4 Esempio di cupsd.conf . . . . . . . . . . . . . . . . . . . . . 683.5 CUPS: homepage interfaccia web . . . . . . . . . . . . . . . . 693.6 CUPS: sezione stampanti interfaccia web . . . . . . . . . . . . 693.7 CUPS: sezione classi di stampanti . . . . . . . . . . . . . . . . 703.8 CUPS: sezione job di stampa . . . . . . . . . . . . . . . . . . 703.9 Esempio di printers.conf . . . . . . . . . . . . . . . . . . . 713.10 CUPS API: cupsPrintFile . . . . . . . . . . . . . . . . . . . 723.11 CUPS API: cupsGetDest . . . . . . . . . . . . . . . . . . . . 723.12 CUPS API: cupsCancelJob . . . . . . . . . . . . . . . . . . . 723.13 CUPS API: struttura cups_dest_t . . . . . . . . . . . . . . . 733.14 CUPS API: cupsLastError e cupsErrorString . . . . . . . 733.15 CUPS API: cupsGetPPD() ppdOpenFile() ppdClose() . . . . 743.16 lpadmin: sintassi generale . . . . . . . . . . . . . . . . . . . . 753.17 cupsaddsmb: sintassi . . . . . . . . . . . . . . . . . . . . . . . 763.18 smb.conf: uso delle stampanti CUPS . . . . . . . . . . . . . . 783.19 stampa di rete tra client server eterogenei . . . . . . . . . . . 793.20 smb.conf: download automatico dei driver e condivisione delle

stampanti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.21 lpadmin: impostazione coda remota ipp: sintassi . . . . 823.22 lpadmin: impostazione coda remota ipp: sintassi . . . . 823.23 lpadmin: impostazione coda remota ipp: sintassi . . . . 83

Bibliogra�a

[1] Licenza GNU/GPL: http://www.gnu.org/copyleft/gpl.html

[2] Linux-Cifs: sito u�cialehttp://www.microsoft.com/italy/sam/lic_cal_win2003_server.mspx

[3] Microsoft.com: Windows Server2003 overviewhttp://www.microsoft.com/italy/sam/lic_cal_win2003_server.mspx

[4] Samba 3: Nuove Funzionalitàhttp://us3.samba.org/samba/whatsnew/samba-3.0.2a.html

[5] Introduzione all'Active Directoryhttp://www.itprc.com/active_directory.pdf

[6] Introduzione Protocollo Ldaphttp://www.innosoft.com/ldapworld/

[7] Analisi delle prestazioni samba e�ettuato da Hphttp://us3.samba.org/samba/ftp/slides/enterprisesamba.pdf

[8] Analisi delle prestazioni di Samba e�ettuato da PCMAGhttp://www.pcmag.com/article2/0,1759,17201,00.asp

[9] http://www.idgworld.it/networking/nwi2000/S01a0302.htm

[10] http://euro.asphi.it/topcourses/ctscourseit/internet_addresses.html

[11] http://euro.asphi.it/topcourses/ctscourseit/internet_addresses.html

[12] Ethereal: Sito U�ciale http://www.ethereal.com

[13] Netbeui: Introduzione http://utenti.lycos.it/Lucauby/netbeui.html

[14] Netbios: Implementazione nelle reti Microsofthttp://www.microsoft.com/windows2000/it/server/help/

default.asp?url=/windows2000/it/server/help/sag_DHCP_add_OptionsNetBIOS.htm

[15] Linux Kongress: stampare con Sambahttp://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/

86

BIBLIOGRAFIA 87

[16] SWAT: Samba Web Adminitration Toolhttp://www.openskills.info/view/boxdetail.php?IDbox=781

[17] SWAT e SSL: How-to http://fi.samba.org/docs/swat_ssl.html

[18] Smb4k: sito u�ciale http://smb4k.berlios.de

[19] Snia: speci�che u�ciali CIFS http://linux-cifs.samba.org/

[20] Netatalk: sito u�ciale http://netatalk.sf.net

[21] Netatalk: manuale u�cialehttp://netatalk.sourceforge.net/2.0/htmldocs/intro.html

[22] Netatalk: sito progetto su sourceforgehttp://sourceforge.net/projects/netatalk

[23] Codi�ca UTF8: sito u�ciale http://sourceforge.net/projects/netatalk

[24] Sleepycat Software: sito u�ciale http://www.sleepycat.com

[25] Codi�ca UTF8: sito u�ciale http://www.sleepycat.com

[26] SSLeay http://www.ssleay.org

[27] OpenSSL: sito u�ciale http://www.openssl.org

[28] PGP UAM: sito riferimento http://www.vmeng.com/vinnie/papers/pgpuam.html

[29] Protocollo DES: sito riferimento http://www.itl.nist.gov/fipspubs/fip46-2.htm

[30] Protocollo Di�e-Hellman Exchange: sito riferimentohttp://www.rsasecurity.com/rsalabs/node.asp?id=2248

[31] Rfc 1179 LPD speci�cation http://www.faqs.org/rfcs/rfc1179.htm

[32] Rfc 2616 LPD speci�cation http://www.faqs.org/rfcs/rfc2616.htm

[33] Easy Sowtware: sito u�ciale http://www.easysw.com/

[34] Immagini raster: esempi e tutorialhttp://scv.bu.edu/Tutorials/ImageFiles/image101.html

[35] Apache web server: sito u�ciale http://httpd.apache.org/

[36] CUPS: sito u�ciale http://www.cups.org/

[37] CUPS: pagine u�ciali di ducumentazionehttp://www.cups.org/documentation.php

[38] MIcrosoft: Implementazione e uso di IPP tramite IIShttp://www.microsoft.com/windowsserver2003/techinfo/overview/internetprint.mspx

BIBLIOGRAFIA 88

[39] GimpPrint: Sito U�ciale http://gimp-print.sf.net

[40] The GIMP: Sito U�ciale http://www.gimp.org

Documents

Samba, Cups e Netatalk: condivisione di risorse in ambito ... · UNIVERSITÁ DEGLI STUDI DI MODENA E REGGIO EMILIA acoltàF di Ingegneria - Sede di Modena Corso di Laurea in Ingegneria