Samba, Cups e Netatalk: condivisione di risorse in ambito Linux

Transcript

1 UNIVERSITÁ DEGLI STUDI DI MODENA E 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: Prof.ssa Letizia Leonardi Tesi di Laurea di: Luca Martinelli Correlatore: Ing. Luca Ferrari Anno Accademico

2 Indice 1 Samba Introduzione Caratteristiche Funzionamento: una generica sessione Samba Concetti di Windows Networking File sharing & print sharing Samba Printing Analisi pacchetti Netbios e Netbeui Autenticazione Dettaglio pacchetti Esempio di congurazione di Samba Applicazioni che costituiscono Samba Evoluzione di Samba: CIFS Netatalk Introduzione AppleTalk e lo standard ISO/OSI Una implementazione del protocollo Appletalk Compilazione e installazione di Netatalk Congurazione di Netatalk Congurazione di AppleTalk Routing Congurazione di un File Server Principali Utility di Netatalk Cups Introduzione Introduzione a IPP Concetti generali PostScript RIP Spooler e Demoni di Stampa File PPD

3 INDICE Struttura di CUPS Scheduler Conguration File Congurazione del server HTTP File di congurazione per stampanti Tipologie MIME supportate CUPS API Berkeley and System V Commands lpstat lp status lpc status lpq lprm e cancel lpadmin cupsaddsmb lpinfo Filters foomatic pap CUPS Imaging Backends Samba Backend Network Printing Bibliograa 86

4 Capitolo 1 Samba 1.1 Introduzione Samba e` un progetto fondato nel 1991 da Andrew Tridgell, al quale oggigiorno contribuiscono attivamente una decina di sviluppatori. Samba è Software Libero distribuito con licenza GPL [1]. Questo software rende trasparente l'integrazione tra Unix e Windows, poichè Samba funziona bene su molte piattaforme (GNU/Linux, Mac Os-X, Solaris, HP-UX, AIX, True64, *BSD, e altre ancora), implementando un server SMB. SMB è un famoso protocollo di condivisione delle risorse adottato sul nire degli anni Ottanta da molti produttori per fornire funzionalità di condivisione di le, directory e stampanti all'interno di una rete locale. Tra questi produttori c'era anche Microsoft, che decise di includere il protocollo all'interno del suo sistema operativo Windows per l'erogazione dei servizi di rete. La scelta si rivelò strategica per la casa di Redmond che raorzò il supporto a SMB in tutte le release successive dei propri sistemi operativi. Oggi SMB è più che mai presente nei sistemi Microsoft anche se recentemente ha cambiato il suo nome in CIFS (Common Internet File System)[2]. Un Protocollo onnipresente Come conseguenza naturale dell'adozione di SMB da parte di Microsoft, attualmente esistono svariati milioni di computer Windows che fanno uso di questo protocollo, creando così uno standard di fatto per i servizi di condivisione delle risorse. Ogni volta che si clicca sull'icona di Risorse di Rete oppure ogni volta che si lancia una stampa su una unità condivisa da Windows, si sta in qualche modo utilizzando il protocollo SMB. Nonostante la presenza quasi esclusiva in ambito Windows, SMB è un protocollo aperto e non un sistema chiuso sotto la proprietà di Microsoft. Qualunque produttore o gruppo di sviluppo può implementarlo per fornire servizi di condivisione su qualunque sistema e piattaforma, garantendo una piena compatibilità Windows. Questo è proprio quello che fa il progetto Samba: fornire servizi di condivisione per accedere in maniera trasparente 3

5 CAPITOLO 1. SAMBA 4 alle reti Windows da postazioni Unix e viceversa. Il progetto esiste da lungo tempo ma si può certamente aermare che la diusione più rilevante di Samba si ha con la versione 2.2 nella piattaforma Linux. Il successo è stato dato dalla credibilità del sistema operativo stesso e dall'allettante possibilità di replicare quasi completamente le funzionalità di un server Windows NT4 senza sostenere costi di licenza. Installando Samba in un le server era possibile risparmiare subito circa mille euro di licenza Windows Server più tutte le CAL[3] 1 richieste per ogni client che accede ai servizi centralizzati. Un vantaggio non indierente per piccole e medie imprese, organizzazioni senza scopo di lucro ed enti governativi. Panoramica di Samba 2.2 La versione 2.2 di Samba funziona grazie a due demoni generalmente attivati in fase di avvio dal sistema operativo. Si tratta di smbd e di nmbd. Il primo provvede alle funzioni di autenticazione e di condivisione delle risorse. Il secondo implementa invece i servizi di risoluzione dei nomi, compreso WINS (Windows Internet Naming Service) 2 e le funzioni di browsing necessarie per l'elenco dei computer in Risorse di Rete. Non bisogna infatti dimenticare che questo elenco non è dinamico e neppure aggiornato in tempo reale, ma è piuttosto mantenuto da un computer sulla rete. Questo a intervalli regolari provvede ad aggiornare l'elenco in base a un algoritmo ben denito. I client fanno riferimento a questo elenco per visualizzare l'elenco dei membri della rete locale. E' per questo motivo che non sempre si riesce a vedere in rete un computer appena acceso o si trovano ancora in elenco computer che risultano invece spenti già da diversi minuti. I demoni smbd e nmbd svolgono nel complesso la totalità delle funzioni presenti in Samba 2, garantendo un comportamento simile a quello di un server Windows NT4. Samba 2.2 può svolgere funzioni di workgroup o di PDC, può autenticare gli utenti in modalità debole compatibile Windows 9x, può autenticare in modalità NT, supporta la browsing list e gestisce in buona misura i criteri di sistema, come verrà spiegato in seguito. Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password (SAM) 3 : quando un client cerca di accedere alle risorse di un server, quest'ultimo verica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l'accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse accessibili. Il database delle password viene automaticamente copiato ad uno o più Backup Domain Controller (BDC) eventualmente pre- 1 Nei modelli di licensing Windows Server è necessaria una licenza Server per ogni copia del software server installata, oltre a una licenza CAL (Client Access License) per ogni utente o dispositivo che accede o utilizza il software server. 2 Il servizio che nelle reti Microsoft viene utilizzato per la traduzione dei nomi in indirizzi. 3 Security Account Manager: sistema per la memorizzazione delle password e dati account utente in un dominio Microsoft

6 CAPITOLO 1. SAMBA 5 senti nella rete i quali possono essere utilizzati per autenticare i client nel caso in cui il PDC risulti inaccessibile. Sul server si possono poi congurare un numero arbitrario di condivisioni e creare tutti i presupposti per l'erogazione di cartelle pubbliche e di home directory, tutte protette con diritti a livello di utente. Quanto basta insomma per sostituire un server NT4 in molte situazione reali. La congurazione e la manutenzione del sistema Samba avviene, secondo la tradizione Unix, tramite le testuali da editare manualmente. Esistono comunque strumenti graci per semplicare la gestione di Samba. Tra questi è interessante Swat, un front-end Web per l'amministrazione del sistema, che verrà analizzato in seguito. Pur essendo molto funzionale, Samba 2.2 è comunque privo di alcune caratteristiche importanti. Non è per esempio contemplato il ruolo di BDC, non sono supportate le relazioni di ducia tra server Windows e server Samba e non è possibile amministrare la lista degli utenti e dei gruppi usando il tool di gestione di Windows NT4. Il divario si è poi allargato, dal momento che Microsoft non si è fossilizzata sulle caratteristiche di Windows NT4, ma ha incrementato piuttosto la rosa di funzionalità di rete nelle successive release di Windows 2000 Server e Windows Server La versione corrente: Samba 3 Gli equilibri sono stati nuovamente ripristinati con Samba 3, rilasciato nel settembre Questa versione ha colmato un elevato numero di carenze, guadagnando nuovamente terreno sull'oerta Microsoft e tornando nuovamente a essere un'alternativa interessante. Il progetto è stato in seguito aggiornato no all'attuale Queste release successive hanno comunque avuto solo ruoli correttivi nei confronti di bug strutturali o di falle di sicurezza[4]. Con questa versione delle suite Samba è stata aggiunta una funizionalità importante il supporto per Active Directory 4. Si tratta della possibilità di unirsi come membro a una struttura ADS (Active Directory Service) preesistente, con la facoltà di autenticare utenti tramite il protocollo Kerberos e di utilizzare LDAP (Lightweight Directory Access Protocol) 5 per la memorizzazione delle informazioni di rete. Tutto questo è un notevole passo in avanti, ma permangono alcuni limiti rilevanti. Occorre innanzitutto spiegare che i protocolli che regolano il funzionamento dei domini Windows non sono in realtà aperti, ma sono un segreto industriale ben custodito da Microsoft, e quindi non esiste quindi alcuna documentazione tecnica liberamente disponibile. Gli sviluppatori di Samba non possono fare altro che compiere esperimenti sui domini ed esaminare il traco di rete per cercare di dedurre il comportamento dei protocolli. Si tratta di un estenuante lavoro di reverse engineering. 4 Active Directory Service: il servizio di directory Microsoft. Network Directory è una struttura organizzativa delle le risorse all'interno di una rete (utenti, autenticazioni, condivisioni, stampanti) gestita in modo centralizzato[5]. 5 LDAP è un insieme di speciche per un protocollo client-server per ottenere memorizzare informazioni centralizzate come Network Directory[6].

7 CAPITOLO 1. SAMBA 6 Nonostante il chiaro intento da parte del gruppo di sviluppo di emulare completamente l'ambiente di Active Directory, in Samba 3 sono state sviluppate anche le caratteristiche di dominio NT4. La scelta è derivata dalla seguente motivazione: esiste ancora una percentuale elevata di utenti NT4 Server, addirittura superiore alle previsioni di Microsoft, ed è bene fornire supporto a questa categoria di utilizzatori. Bisogna considerare che la maggior parte delle PMI (Piccole e Media Industrie) non ha bisogno di tutte le caratteristiche evolute di rete introdotte a partire da Windows 2000 Server. Un ambiente aperto, senza costi di licenza e in grado di emulare Windows NT4 Server è già più che suciente per una consistente fetta di mercato. Samba 3 permette di migrare completamente un ambiente NT4 Server mantenendo le informazioni sugli utenti e sui gruppi, in questo processo vengono preservati anche i SID (Single Identier), gli identicatori unici Windows di sicurezza per gli oggetti gestiti sul server. Grazie a questa capacità i client potranno essere integrati in maniera trasparente e senza alcun lavoro supplementare. E' supportato sia il ruolo di PDC (presente già da tempo) che quello di BDC, una novità per Samba. I tool di amministrazione presenti su Windows possono essere usati per amministrare questo ambiente, rendendo più semplice la gestione da parte dello sta tecnico. I domini creati con Samba non sono isolati, ma possono istituire relazioni di ducia con controller di dominio basati su Windows. Questa era una delle carenze più sentite in Samba 2.2, in quanto l'assenza delle trust impediva l'uso di Samba in realtà complesse dotate di molti domini. I nomi delle risorse possono essere composti ora in maniera più cosmopolita grazie all'inclusione di unicode: esiste ora piena facoltà di avere nomi realmente internazionali con alfabeti non occidentali. E' inne degna di nota la scelta di introdurre un comando net ispirato all'omonimo comando Windows per l'esecuzione di un gran numero di funzioni di rete. L'obiettivo dichiarato è quello di sostituire progressivamente la miriade di utility e comandi di supporto a Samba con le opzioni incorporate all'interno dell'unico comando net. Si tratta di una scelta interessante, che permette di semplicare la gestione del sistema con un numero limitato di istruzioni da linea di comando. Samba 3 può essere a tutti gli eetti considerato una implementazione libera e gratuita del protocollo SMB/CIFS, con esso, una macchina GNU/Linux, può accedere alle risorse condivise di un elaboratore MS-Windows ma anche mettere a disposizione proprie risorse a clienti MS-Windows o GNU/Linux. Più in dettaglio ecco quali sono i servizi oerti da Samba: : server per orire la condivisione di le system e stampanti; client per l'accesso a risorse NetBIOS su macchine Unix, MS-Windows, Novell remote; master browser (sia locale che di dominio); server WINS (Windows internet name service);

8 CAPITOLO 1. SAMBA 7 server per l'autenticazione di clienti di un dominio MS-Windows. 1.2 Caratteristiche Le caratteristiche principali oerte da Samba sono: Integrazione In molti scenari sono utilizzati ambienti eterogenei con server e client di diversa natura. E spesso è necessario far dialogare questi sistemi. Molto spesso inoltre i client sono Windows, mentre i server sono di dierenti tipologie Unix, Novell, NT eccetera. Samba permette di integrare server GNU/Linux, BSD, o Unix (e altri) in una rete in cui si deve convivere con client MS Windows senza dover installare software aggiuntivo sui client. Il server Samba viene percepito come un server Windows NT e consente di condividere le e stampanti su una rete Windows senza troppi sforzi. Samba è inoltre ottimo come server di stampa, accopiato a CUPS o lpr permette anche un sistema essibile e avanzato di accounting delle stampe, ad esempio consentendo a macchine Windows di utilizzare stampanti installate su macchine *nix o viceversa a macchinue *nix di stampare su risorse collegate a sistemi Windows. Costo Samba viene utilizzato spesso per permettere ai client Windows di vedere i le residenti su sistemi tipo *nix e permettere in questo modo alle piattaforme Windows di interoperare con le piattaforme server. Samba viene però anche sempre più utilizzato in sostituzione di File Server NT o Novell in quanto permette di ridurre sensibilmente i costi di licenza per l'accesso dei client e ottenere un'alta adabilità del servizio. Infatti molti sistemi le server/print server/domain controller proprietari richiedono oltre al pagamento di una licenza d'uso per il server in sè, anche di licenze di connessione per ogni client che deve utilizzare tale server (CAL). Molte aziende possono permettersi di impiegare un server basato sull'accoppiata Linux/Samba, in quanto le eettive necessità centralizzate sono generalmente limitate. Non bisogna dimenticare che gran parte dei server NT o 2000 vengono utilizzati solamente per le loro funzionalità di le server. In pratica si sfrutta il sistema come contenitore centralizzato dove salvare i documenti di lavoro e le cartelle personali degli utenti, impiegando poi un sistema di storage per eseguire il salvataggio di tutta l'informazione aziendale in un colpo solo. Queste funzionalità sono estremamente preziose per la miriade di PMI che popolano lo scenario industriale italiano, anche se in n dei conti si tratta di necessità tecnologiche molto semplici [9]. L'economicità di un sistema GNU/Linux riguarda soprattutto i requisiti hardware richiesti: GNU/Linux gira anche su hardware cosiddetto obsoleto. Ciò si traduce in un risparmio economico poichè non sono necessari frequenti aggiornamenti hardware. È stimato, infatti, che la vita me-

9 CAPITOLO 1. SAMBA 8 dia dell'hardware, utilizzando GNU/Linux raddoppi da 3 a 6 anni (Windows richiede in media il raddoppio delle risorse hardware di versione in versione)[10]. Flessibilità Samba facilita le operazioni di consolidazione di più servizi su un singolo server. E' possibile anche congurare più istanze di Samba su un server che abbia più interfacce di rete. Non solo, Samba è già predisposto per IP failover 6, ed è estremamente essibile e dotato di un numero eccezionale di opzioni con cui ottimizzare il proprio server e congurarlo per fare le cose come più aggradano. Inoltre già dalla versione 2.2, Samba supporta dierenti sistemi di autenticazione e salvataggio dei dati degli utenti. Si possono mantenere gli account degli utenti sul classico le smbpasswd, o sul più modermo ldap o tdbsam. Non dimentichiamo inoltre winbind un demone che permette di utilizzare sulla macchina *nix gli utenti impostati su di un dominio NT. Prestazioni Le attuali versioni di Samba sono un ottimo sostituto per un server Windows che fornisce condivisione di le e stampanti. Come dimostrano i test comaparativi tra Samba e Windows 2000 server eettuati da PCmag [8]e Hp [7]. Il test è stato eetuato su 3 diversi diversi tipi di hardware: fascia bassa Micron ClientPro XLU Pentium II/ MB Ram fascia media Dell Dimension XPS T Mhz PIII 256 MB Ram fascia alta Dell Dimension 4100, 1Ghz p3 512 Mb Ram Tutte le macchine erano equipaggiate con HardDisk Ide e schede rete 3Com 3C905C. Per i test è stata utilizzata la suite di test Netbench 7.02, congurando 30 client per generare suciente traco di rete. Su entrambe le macchine Windows e Linux sono stati eliminati i servizi non necessari (server web serve ftp) inoltre sulla macchina Linux è stato ricompilato il kernel per eliminare i moduli non necessari. Sui due tipi di sistema non sono state eseguite particolari ottimizzazioni benchè entrambi possiedano di default impostazioni che permettono una buona gestione del cahing dei le. Anche causa del comportamento più aggressivo di Samba per quanto riguarda il caching dei le si può notare come nel graco del tempo medio di risposta (gura 1.2) a parità di hardware ora prestazioni migliori del concorrente. Nell'altro graco (gura 1.1) possiamo notare che servendo pochi client Samba e Windows presentino valori di throughput praticamente uguali mentre al crescere del numero di Host samba fornisce prestazioni migliori. 6 Se un server non risponde più alle richieste, può essere rimpiazzato da un altro che ne acquisisce l'ip, il tutto in maniera trasparente rispetto agli altri servizi di rete.

10 CAPITOLO 1. SAMBA 9 Figura 1.1: Troughput Figura 1.2: Response time

11 CAPITOLO 1. SAMBA Funzionamento: una generica sessione Samba In questo paragrafo verrà analizzato il funzionamento di una generica sessione Samba e verranno introdotti alcuni concetti fondamentali di Windows Networking utili a comprendere il funzionamento della sessione stessa Concetti di Windows Networking Nella sua forma più semplice il sitema di Windows Naming è basato su un modello di tipo broadcast. Un sistema che vuole partecipare ad una network Windows dionde il suo nome Netbios a tutti gli altri host della subnet in cui è inserito. Se nessun altro sistema si oppone il nome è associato alla macchina e si può procedere al suo utilizzo. Per identicare un sistema dal nome, il nome richiesto è mandato in broadcast per tutta la rete e il sistema che possiede il nome è l'unico a rispondere. Samba è in grado di fornire e partecipare a questi servizi sia per quanto riguarda registrazione del nome sulla rete che per la ricerca di altri nomi. NetBios Name Service è fornito dal componente nmbd, che permette ad una *nix box di registrare il suo nome ed essere riconosciuta dai sistemi Windows. La suite Samba include anche l'utility nmblookup che ha funzionalità simili a quelle che nslookup ore per il Domain Naming Service. Grazie a questo compontente si può ricavare l'indirizzo associato ad un nome netbios. Ogni sistema Windows può avere più di un nome Netbios associato. Un nome identica l'host, un'altro nome può essere associato all'utente loggato sul sitema. Il sistema di registrazione dei nomi tramite broadcast funziona su reti piccole e su una singola subnet, ma genera molto traco e non è scalabile. Il browsing di una rete permette ad un utente di vedere i nomi degli host sulla rete. Per fare ciò, l'host in questione deve aver ricevuto e memorizzato tutte le corrispondenze dei nomi della rete e host connessi. Per questo motivo sono stati classicati gli host in master browser e name server. Per supportare il browsing della rete si usano i master browser, che mantengono in cache le informazioni di broadcast degli altri sistemi. Quando un sistema vuole visitare le Risorse di rete non fa altro che interrogare il master browser, senza generare traco superuo. Il master browser è scelto tramite un processo di elezione. Se il master browser è riavviato o risulta non disponibile, si ha un elezione tra le workstation rimanenti per il ruolo di master browser. Samba può essere usato come master browser in una sessione di Windows networking, puo essere congurato sia per forzare una elezione di un browser sia per partecipare ad essa. L'utilizzo di un master browser dipende dall'archittetura della rete infatti è noto che il broadcast non funziona attraverso router e subnet dierenti.

12 CAPITOLO 1. SAMBA 11 Per funzionare attraverso router, il servizio di name service ha bisogno di un name server dedicato detto WINS. Il Windows Internet Naming Service (WINS) [11] serve a trasformare i nomi dei computer in indirizzi IP per l'instradamento e la consegna dei pacchetti. WINS è studiato per arontare il problema dell'individuazione di risorse di rete in ambiente TCP/IP attraverso la congurazione e il mantenimento automatici delle tabelle di mappatura dei nomi NetBIOS e degli indirizzi IP, svolgendo insieme funzioni elementari come impedire la duplicazione di nomi in rete. WINS è un servizio complemetntare per il DHCP e possiede una strumentazione completa e centralizzata per l'amministrazione e la congurazione di server WINS, tabelle nomi statiche e informazioni di duplicazione. Anche se nella rete è attivo un servizio Wins, i client continuerano a interrogare il master browser. Quest'ultimo si rivolgerà al server Wins per la risoluzione dei nomi, ripsondendo alle richieste dei client. Samba può quindi essere impostato per usare un Wins server pre-esistente, può essere integrato in una rete Microsoft come una normale workstation, senza assolvere funzioni speciali. Samba alternativamente può anche funzionare in sostituzione di un server Wins, tutti i vantaggi descritti per l'af- dabilità di GNU/Linux come master browser valgono anche se si utilizza come server wins File sharing & print sharing La maggior parte dei modelli di le sharing che sono oerti nei sistemi Windows sono disponibili con Samba. Grazie al supporto di linux per le home directory, queste utlime possono essere esportate e accessibili dai client Windows, gli utenti che si loggano al sistema hanno accesso alla loro directory privata. Le condivisioni di Windows hanno principalmente due tipi di controllo di accesso: livello condivisione: a ogni disco, cartella, le o stampante condivisa viene assegnata una password livello utente: ad ogni risorsa condivisa si può assegnare un elenco di utenti che vi possono accedere Samba supporta entrambi i tipi di controllo di accesso, l'utente non nota quindi nessuna dierenza rispetto a un server Windows e non necessita di alcun software aggiuntivo da installare sui client. Samba ore inoltre l'abilità di memorizzare i proli degli utenti all'interno delle condivisioni, grazie a ciò un utente può cambiare workstation e avere con lui le stesse impostazioni e preferenze (desktop, menu, ecc.).

13 CAPITOLO 1. SAMBA Samba Printing Oltre che alla condivisione di le Samba, può essere usato per la condivisione delle risorse di stampa. Samba fornisce quindi l'accesso alle macchine Windows delle stampanti Unix. Alcuni sistemi Windows devono inoltre essere in grado di scaricare i driver di stampa dal server che condivide la stampante. Tutto ciò può essere fatto senza lavoro aggiuntivo dell'utente ma con un piccolo setup iniziale. Se il sistema di stampa *nix è aggiunto ad alcuni pacchetti di stampa postscript (come Ghostscript) allora è possibile per i sistemi Windows usufruire di servizi che altrimenti non avrebbero a disposizione. Per gli utenti unix che vogliono stampare su macchine Windows è a disposizione l'utility smbprint, questa può essere chiamata dall'utente o usata come ltro. Cenni sulla stampa Windows Windows in origine fu sviluppato per un utilizzo da parte di un singolo utente, ciò signica che per prima venne sviluppata una printig API (Aplication Program Interface) locale. Sucessivamente venne progrettato un protocollo per fornire un sistema di stampa remoto tramite la API locale. Indubbiamente la stampa Windows è molto più semplice da usare per utenti e programmatori ma presenta alcuni problemi. Ci sono pricipalmente quattro diversi modi per stampare in Windows: 1. Printing spooling path; 2. Win 3.X printing system; 3. Win 9X point-and-print path (RAP calls); 4. Windows NT/2000/XP printign system (DCE/RPC ). Printing spooling path Questo è il sistema di stampa in origine utilizzado dal DOS, il cui meccanismo consiste nell'aprire una periferica (LPT ad esempio) e inviare al suo interno dei dati. Questo sistema di stampa può essere utilizzato da remoto tramite SMBsplopen, fornendo però solo un rudimentale supporto per il monitoraggio della coda di stampa. Tramite il printing spooling path non è introdotto il concetto di driver nel sistema operativo, ciascun applicativo utilizza un driver a se stante per l'uso della periferica. Windows 3.x printing system Windows 3.x è stata la prima versione di Windows ad avere incorporato il concetto di driver indipendenti dall'applicazione. Questi driver devono essere installati su ciascun client (il concetto

14 CAPITOLO 1. SAMBA 13 di client che scarica automaticamente i driver fu introdotto con win9x), oggigiorno 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 automaticamente al momento del setup i le del driver per una stampante collegata. I client Windows 9x usano le chiamate RPC (Remote Procedure Call) per ottenere le informazioni sul driver da scaricare, questo include il percorso da cui prelevare i driver, e le informazioni sulla stampante (nome, collocazione,commenti ecc). Rispetto all'implementazionde delle printing API di Windows 3.1 sono state aggiunte nuove funzionalità che consentono un maggiore controllo delle code di stampa (come pausa, cancellazione, pulizia coda di stampa). Windows NT/2000/XP printing system Windows NT/2000/XP hanno un metodo di stampa completamente dierente, dalle precedenti versioni. delle chiamate SMB aprono la connessione alla condivisione \\SPOOLSS creando una pipe; delle chiamate DCE/RPC sono eettuate alla pipe SPOOLSS per aprire la connessione alla stampante, creare nuova stampante, aggiungerne i driver. Tramite questa implementazione tutto ciò che può essere fatto localmente utilizzando le chiamate alle Printing API, può essere eseguito da remoto. Il tallone di achille di questa struttura è il sistema di spooling (notoriamente instabile) al quale arrivano le chiamate delle API[15]. Tutte le comunicazioni di stampa eettuate usando DCE/RPC funzionano 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, Samba deve implementare tutti e quattro i sistemi sopra elencati. Ecco elencate alcune della maggiori dicoltà nell'implementazione di questa struttura. l'impelementazione DCE/RPC è terribilmente complessa;

15 CAPITOLO 1. SAMBA 14 il sistema di spooling è delicato e instabile, se vengono inviati ad esso dati formattati non correttamente oppure dati inattesi, va irrimediabilmente in crash; in Win NT4.x i driver venivano utilizzati in Kernel mode, in Windows 2000 vengono utilizzati in User Mode; non c'è protezione dalle race condition, ossia se due amministratori installano dei driver contemporaneamente ciascuno può fare danno all'altro. Per far fronte alle problematiche sopra esposte, venne creata una sezione dedicata nel progetto Samba chiamata Samba Printer Code la quale ore alcune caratteristiche molto interessanti: fornisce la possibilità di download dei driver; fornisce possibilità di immagazzinamento remoto per dati di stampa; consente il mapping tra le stampanti Windows le code di stampa Unix. Samba Printer Code utilizza un database interno tdb (technical database) per la memorizzazione delle informazione quali ad esmpio la capacità della stampante. Conseguentemente ad ogni arrivo di job nella coda di stampa una nuova entry è aggiunta nel database. Il passo sucessivo del processo di stampa consiste nel memorizzare i dai all'interno di un le temporaneo. Per rilevare lo stato della stampante le macchine Windows eseguono il polling, se venisse creata un istanza di lpq sulla macchina unix per ogni richiesta si otterrebbe una notevole diminuzione delle prestazioni. Memorizzando nel database tdb le informazioni sull'ultimo stato della coda si può evitare l'esecuzione di numerosi lpq sostituendoli con interrogazioni alla base dati. Purtroppo allo stato attuale dello sviluppo solo CUPS implementa appieno le chiamate API, gli altri si limitano a nascondere sotto le interfacce i classici strumenti (lpq, lprm, lpc). Per concludere la trattazione della stampa tramite Samba ecco alcuni dei principali obiettivi che gli sviluppatori si sono posti: migliorare e arricchire le Unix printig API; migliorare i driver per le stampanti inkjet, (le stampanti con emulazione postscript sono supportate abbastanza bene). 1.4 Analisi pacchetti In questo paragrafo verranno analizzate le principali caratteristiche dei protocolli Smb, Netbios e Tcp/Ip e la loro collocazione all'interno dello stack

16 CAPITOLO 1. SAMBA 15 Figura 1.3: stack tcp e posizione protocollo smb del modello protocollare TCP/IP (g1.3)sui quali si basa il funzionamento di Samba Netbios e Netbeui I protocolli NetBIOS ed NetBEUI [13] sono stati sviluppati rispettivamente nel 1983, dalla Sytek per IBM, e nel 1985 da IBM stessa. Ancora oggi restano molto diusi nei sistemi Microsoft, in virtù dei loro pregi nell'ambito delle reti locali. Con l'introduzione di Token Ring, IBM nel 1985 denì delle estensioni a NetBios (NetBIOS Extended User Interface NetBEUI) che permettevano di appoggiarsi ad un data-link (Token Ring o Ethernet). Microsoft ha iniziato ad usare NetBEUI come protocollo di rete su Windows for Workgroup (Windows 3.1) e poi su tutte le versioni successive ma, al contempo, con la diusione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche su IPX e IP, oltre che su altri protocolli. All'epoca, l'obiettivo era infatti quello di creare un protocollo su misura per le LAN di dimensioni contenute (no a circa 200 nodi), quindi doveva essere piccolo, semplice, veloce e doveva permettere di assegnare nomi umani alle risorse, invece dei complessi indirizzi usati dal TCP/IP. Inoltre NetBIOS è stato progettato perchè usasse intensamente i broadcast (messaggi uno a tutti), piuttosto che interrogare un'entità centralizzata. In questa logica, un computer che in seguito all'accensione voglia registrarsi con il proprio nome NetBIOS come nuovo nodo, deve inviare appositi messaggi broadcast per farsi accettare come nuovo nodo attivo. Se il nome è già usato, il precedente possessore di quel nome deve inviare un messaggio di risposta per respingere la scelta. Se invece un computer vuole localizzare un nodo preesistente, invierà ancora altri broadcast nel tentativo di contattare quello specico nodo. Il computer remoto è sempre tenuto a rispondere ai

17 CAPITOLO 1. SAMBA 16 broadcast con un messaggio unicast (uno a uno). Solo successivamente i due computer potranno comunicare senza usare broadcast. Per essere più precisi, l'implementazione del NetBEUI nei sistemi Microsoft dierisce dalle ultime versioni del NetBEUI standard (NetBEUI 3.0) per alcuni aspetti, pur preservandone la compatibilità. Ad esempio, il Net- BEUI di Microsoft, chiamato NBF (NetBIOS Frame), presenta alcune migliorie rispetto al protocollo standard, ed invece di interfacciarsi con i livelli superiori tramite il consueto NetBIOS, utilizza un'altra interfaccia più essibile, chiamata TDI, Transport Driver Interface, cioè interfaccia del dispositivo di trasporto. I nomi usati da NetBIOS sono fatti di 16 caratteri alfanumerici e possono essere di due tipi: nomi unici: possono essere usati per identicare al più una sola risorsa in rete nomi di gruppo: che invece si associano a più nomi unici In ambiente Windows, un nome unico può individuare un computer della rete, un utente loggato su un sistema della rete, sia anche un servizio oerto da un computer (una certa applicazione o una funzionalità particolare). Dato che NetBIOS non dispone dei numeri di porte, come quelle del TCP/IP, per poter identicare queste funzionalità viene riservato il sedicesimo carattere, che diventa un susso e quindi limita il nome a soli 15 caratteri. Le comunicazioni sono di tre tipi: sessioni, datagrammi, broadcast. Le sessioni si usano per scambiare con un altro nodo rilevanti quantità di dati con rilevamento e correzione d'errore. I datagrammi per inviare ad uno o più nodi (quando il destinatario è un gruppo) messaggi di dimensioni modeste ma senza dover stabilire una sessione. I broadcast inne, si usano per comunicare messaggi di dimensioni modeste a tutti i nodi in ascolto. In sessione è possibile inviare no a 64 Kbyte di dati per messaggio. Con i datagrammi si è limitati a 512 byte per messaggio ed inoltre non si ha la garanzia che i dati arrivino. Tuttavia, negli ambiti in cui queste limitazioni non costituiscono un problema insormontabile, lavorare con i datagrammi rimane molto semplice e veloce. Per distinguere il traco in una stessa rete è stata sviluppata un'apposita funzionalità, chiamata NetBIOS Scope ID. Si tratta di una stringa di caratteri aggiunta alla ne del nome. Due computer devono avere lo stesso scope ID per comunicare. I limiti di Netbios over Netbeui La diusione di Internet ha messo subito in luce quali sono i limiti di NetBIOS e del suo supporto NetBEUI quando la rete cresce di dimensioni. Tralasciando problemi seri ma non insormontabili, come il degrado prestazionale sulle WAN legato all'uso dei

18 CAPITOLO 1. SAMBA 17 broadcast, rimangono tuttavia altri problemi di non facile soluzione: innanzitutto l'unicità nomi. Dato che due computer non possono usare due nomi uguali nella stessa rete, bisognerebbe trovare un nome diverso per ogni computer connesso, cosa non banale in una rete geograca. In secondo luogo, a causa dela non gerarchicità dei nomi, NetBEUI non permette il routing. Cioè, dato un nome NetBIOS, è impossibile sapere quale sia la strada per raggiungerlo. Il problema in questo caso risiede nel fatto che i nomi NetBIOS non contengono alcuna informazione gerarchica. In principio infatti il Net- BIOS fu pensato per reti semplici e non strutturate a dierenza di TCP/IP. Quando la rete diventa Internet, è immediato rendersi conto che un indirizzo IP sia molto più comodo e molto più versatile di un nome normale. Un ultimo problema, forse il più importante, è che i router di Internet non permettono il propagarsi dei broadcast, utili al protocollo NetBIOS quando cerca di localizzare un nodo. Per evitare che il NetBIOS aondasse, tornò molto comodo a Microsoft il fatto di poter abbinare l'interfaccia NetBIOS ad un protocollo molto più essibile del NetBEUI, come il TCP/IP, e limitando l'impiego del NetBEUI nell'ambito delle reti locali tra sistemi Microsoft. In questo modo ogni messaggio elaborato da NetBIOS viene incapsulato in un messaggio TCP/IP, che non sore delle limitazioni di cui parlavamo prima. Chiaramente sorgono nuove complicazioni in seguito alle quali si ebbe la creazione dei servizi WINS (derivante dal servizio DNS diuso in Internet) e la creazione del le LMHOSTS (derivante da HOSTS) 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/IP deve usare indirizzi. Ecco che nasce il NetBIOS over TCP/IP, chiamato anche NBT, descritto negli RFC 1001 e 1002[14]. Esso è in grado di lavorare su reti geograche, basandosi su associazioni tra nomi NetBIOS e indirizzi IP fornitegli dall'esterno. Iniziamo col dire che i nodi, detti NBT, possono operare seguendo quattro modalità standard: b-nodi (nodi broadcast) usano broadcast sia per la registrazione che per la risoluzione dei nomi in indirizzi IP. I b-nodi sorono ancora del problema dei broadcast di NetBIOS: se i nodi sono separati da router, non riusciranno a contattarsi. p-nodi (nodi punto-punto) scoprono l'ip della risorse interrogando con richieste unicast un server WINS noto. WINS, (Windows Internet 7 Host File: le locale memorizzato nel computer con sitema operativo Windows utilizzato per tradurre il nome di dominio in indirizzo IP LmHost File: un le locale memorizzato nel computer con sitema operativo Windows utilizzato per il nome NetBIOS in indirzzo IP

19 CAPITOLO 1. SAMBA 18 Name Service, servizio nomi Internet Windows), è un server, che imitando i server DNS, fornisce una lista di coppie nome NetBIOS indirizzoip. m-nodi (nodi misti) usano prima il broadcast come i b-nodi e poi le richieste come i p-nodi. h-nodi (nodi ibridi) l'opposto degli m-nodi, cioè prima contattano un server WINS noto, poi, se la richiesta ha esito negativo, utilizzano il broadcast. Una volta ricavati gli indirizzi IP corrispondenti ai nomi netbios, si possono aggirare i limiti descritti in precedenza ed è così possibile contattare i nodi remoti. I client Microsoft usano un sistema leggermente più complicato. Consultano in ordine: una cache interna, il server WINS se presente, poi fanno broadcast, e per nire leggono il le LMHOSTS. LMHOSTS è simile al le HOSTS delle macchine UNIX e WINDOWS. Torna utile se non non si dispone di nessun server WINS e non si riesce a risolvere un nome remoto tramite broadcast perchè il nodo è al di la di uno o più router. In realtà LMHOSTS può tornare utile anche se il destinatario risiede nella stessa rete locale. Infatti, per non essere obbligati a subire un'eccesso di broadcast sulla propria rete, è possibile precaricare le associazioni del le LMHOSTS più usate nella cache. Nel protocollo TCP/IP, per stabilire una comunicazione, è necessario denire le porte a cui inviare le richieste. NBT usa prevalentemente le seguenti porte: 137: risoluzione dei nomi NetBIOS (UDP) 138, 139: datagrammi (UDP) 139: sessioni Autenticazione I due principali problemi di sicurezza nella condivisione le sono autenticazione (determinare chi richiede servizio) e autorizzazione (determinare cosa puoò fare chi richiede servizio). I sistemi nix supportano vari tipi di autenticazione (login password, kerberos). Anche Windows ha un sistema di login, che puo essere di tipo locale, oppure login ad un dominio. Samba crea dierenti tipi di integrazione tra i sistemi Windows e i sitemi Unix, per esempio Samba può usare un PDC per l'autenticazione oppure può fornire un autenticazione locale o ancora funzionare lui stesso da PDC per servire l'itera rete Windows. A causa della dierenza dei sistemi di criptazione tra Windows e Unix non è possibile convertire un sistema di autenticazione in un altro, per

20 CAPITOLO 1. SAMBA 19 Figura 1.4: Schermata principale ethereal questo motivo Samba fornisce un meccanismo per mantanere i due livelli di autenticazione separati. A causa della varità di sistemi di autenticazione delle macchine nix questa funzionalità richiede un sforzo di setup iniziale, ma consente di ottenere un vantaggio nell'eliminazione delle richieste di username e password agli utenti e elimina la confusione di dover mantenere password diverse in ambienti diversi. Grazie all'utility rpcclient gli utenti possono cambiare la loro password o interrogare il database delle informazioni nei server Microsoft Dettaglio pacchetti In questo paragrafo verranno dettagliati alcuni esempi di comunicazione tramite protocollo SMB. Per ottenere la cattura dei pacchetti è stato utilizzato il programma Ethereal [12] che è stato installato sulla macchina contenente anche il le server Samba. Sulla rete locale erano presenti solo le macchine che hanno partecipato all'esperimento e sono stati disattivati eventuali servizi che avrebbero potuto compromettere la riuscita ottimale della prova (es: dhpc, ntpd). La cattura delle immagini è avvenuta in due momenti: Cattura dei pacchetti in real time: durante questa fase è stato avviato il programma (con privilegi di root)e sono stati impostati alcuni parametri di congurazione che si possono ossevare in g (1.4)(Capture Package in

21 CAPITOLO 1. SAMBA 20 Figura 1.5: Composizione della rete: server Samba, client Windows XP promiscuous mode, Update list of packets in real time, Automatic scrolling in live capture, Enable MAC name resolution, Enable network name resolution, Enable transport name resolution). Dopo questi settaggi si è iniziata la cattura delle immagini selezionando start capture dal menu del programma. Cessata la cattura dei pacchetti sono state analizzati i dati ottenuti mediante salvataggio di le in un formato compatibile con ethereal. La rete utilizzata per l'analisi dello scambio dei pacchetti è descritta dalla g 1.5, nella quale sono presenti un le server Samba (indirizzo ip ) e un client Windows XP ( ). Dopo l'accensione del client Windows avviene l'avviso tramite broadcast (destinazione ) a tutta subnet della volontà di registare il nome netbios PCXP all'interno del gruppo di lavoro WORKGROUP. Per individuare la dierenza tra nome della macchina e nome del gruppo di lavoro bisogna analizzare i ag del pacchetto nel dettaglio. Per i nomi host è attivo il ag unique, mentre per i nomi del workgroup è attivo il ag group come si può notare in gura 1.6. Nel frame n 16 illustato in g 1.7 avviene l'annuncio dell'avvenuta registrazione dell'host (Host Announcement) nel quale viene indicata anche la tipologia di sitema operativo (NT Workstation). Prima di procedere nella descrizione del funzionamento del processo di elezione del master browser è necessario descriverne il funzionamento nel dettaglio. Esistono varie possibilità di partecipazione al processo elettivo,principalmente come: Master Browser mantiene la lista principale di tutti i computers e delle shares della rete. Tutti i Workgroup o i Domini hanno un master browser;

22 CAPITOLO 1. SAMBA 21 Figura 1.6: ag unique e ag group Domain Master Browser il master browser per un dominio. Il PDC del dominio vince sempre le elezioni per il master Browser; Subnet Browser or Local Master Browser lavora su una subnet fornendo la lista delle risorse ai client e mantendo in costante aggiornamento il domain master browser. generealmente questo ruolo è attribuito al BDC; Backup Browser Il domain master browser manda periodicamente una copia della lista delle risorse al backup browser nel caso di failure del master; Potential browser Un computer che può diventare un master o backup browser; Non-Browser Un computer che non diventerà mai master o backup browser. Siccome in una rete le macchine possono essere connesse e sconnesse in ogni momento, il master browser locale aggiorna continuamente la lista e la invia alle macchine che ne fanno richiesta. Il master browser di dominio invece raccoglie le liste di ogni sottorete e le mette a disposizione dei master browser locali. Un elaboratore diventa master browser locale a seguito di una elezione che può essere eettuata in qualunque momento (ad esempio quando un

23 CAPITOLO 1. SAMBA QuantaCo_2e:6d:f5 Broadcast ARP Who has ? Gratuitous ARP NBNS Registration NB PCXP<00> NBNS Registration NB WORKGROUP<00> NBNS Registration NB PCXP<20> BROWSER Host Announcement PCXP, Workstation, Server, NT Workstation NBNS Registration NB WORKGROUP<1e> BROWSER Request Announcement PCXP BROWSER Host Announcement PCXP, Workstation, Server, NT Workstation, Potential Browser BROWSER Request Announcement PCXP Figura 1.7: Samba pacchetti 1-23

24 CAPITOLO 1. SAMBA 23 [global]... local master = yes os level = 34 preferred master = yes... Figura 1.8: smb.conf: Samba congurato come Preferred Master nuovo elaboratore si presenta in rete). Riguardo a tale elezione Microsoft assegna ai suoi sistemi operativi un valore, detto livello, che cresce sempre di più per i sistemi operativi più recenti (ad esempio una macchina con MS- Windows 98 ha livello 2, una con MS-Windows NT 4 Workstation ha livello 17, una con MS-Windows NT 4-Server ha livello 32, una con MS-Windows 2000-Server ha livello 64). L'elezione avviene sulla base di questo valore, in caso di parità viene esaminata la funzione svolta dalla macchina (si ricordi che un PDC diviene sempre anche Domain Master Browser) in caso di ulteriore parità viene scelta la macchina che è da più tempo in rete. Con Samba il livello per la partecipazione all'elezione può essere scelto in sede di congurazione. Nell'esempio seguente vengono mostrate le direttive da inserire nella sezione [global] del le smb.conf anché il server Samba sia master browser locale prevalendo su macchine MS-Windows no aalla versione NT-server: Dopo l'avvio del computer si può notare come esso annunci se stesso in rete e le sue caratteristiche per partecipare (ed eventualmente vincere)l'elezione del ruolo di master browser (frame 26 e 28). Nei pacchetti 26 e 28 illustati in g 1.9il pc WINXP invia una richiesta in broadcast nella subnet per l'avvio del processo elettivo. Come si può osservare nel dettaglio del pacchetto n 34 (g 1.10) serversmb risponde alle query sul processo elettivo. Da notare in particolare come il server Samba con la congurazione precedente si presenti in rete come un Browse server in standby identicato come Windows NT Workstation. Nel dettaglio del pacchetto 38 (g 1.11)si può notare come il serversmb abbia vinto l'elezione del ruolo di master browser e contemporaneamente di Backup Browser. Nel pacchetto 50 (g 1.12 ) vi è l'annuncio uciale del serversmb come masterbrowser per il gruppo di lavoro WORKGROUP. Nel numero 53 si può notare come il PC xp abbia assunto il ruolo di potential browser, risulta plausibile pensare che diventerà master browser in caso di failure del server serversmb. Nei pacchetti dal 68 al 72 (visibili in g 1.13) si instaura la connessione vera e propria (lo si intuisce anche dall' utilizzo del protocollo SMB). Prima dell'avvio della connessione vera e propria si nota il meccanimo del three way

25 CAPITOLO 1. SAMBA BROWSER Browser Election Request BROWSER Browser Election Request NBNS Name query NB WORKGROUP<1d> BROWSER Browser Election Request NBNS Name query NB WORKGROUP<1d> NBNS Name query NB WORKGROUP<1d> Figura 1.9: Samba: Pacchetti Source IP: Source Port: 138 Microsoft Windows Browser Protocol Command: Browser Election Request (0x08) Election Version: 1 Election Criteria: 0x14010f02 Election Desire: 0x = Backup: NOT Backup Browse Server = Standby: Standby Browse Server = Master: NOT Master Browser = Domain Master: NOT Domain Master Browse Server = WINS: NOT WINS Client = NT: NOT Windows NT Advanced Server Browser Protocol Major Version: 15 Browser Protocol Minor Version: 1 Election OS: 0x = WfW: Not Windows for Workgroups = NT Workstation: Windows NT Workstation = NT Server: Not Windows NT Server Figura 1.10: Pacchetto 34: dettaglio

26 CAPITOLO 1. SAMBA 25 Source IP: Source Port: 138 Microsoft Windows Browser Protocol Command: Browser Election Request (0x08) Election Version: 1 Election Criteria: 0x14010f07 Election Desire: 0x = Backup: Backup Browse Server = Standby: Standby Browse Server = Master: Master Browser = Domain Master: NOT Domain Master Browse Server = WINS: NOT WINS Client = NT: NOT Windows NT Advanced Server Browser Protocol Major Version: 15 Browser Protocol Minor Version: 1 Election OS: 0x = WfW: Not Windows for Workgroups = NT Workstation: Windows NT Workstation = NT Server: Not Windows NT Server Figura 1.11: Samba: dettaglio Pacchetto 38 handshaking nei pacchetti TCP. Nel pacchetto 70 vi è l'avvio della richiesta di connessione al server SMB (NBSS Netbios Session Service) 1.5 Esempio di congurazione di Samba In questo paragrafo verrà descritta la congurazione di Samba utilizzando com esempio la descrizione di un le di congurazione. La congurazione di Samba (i demoni smbd e nmbd) viene gestita dal le smb.conf, un normale le di testo ASCII con queste caratteristiche di massima: I parametri di congurazione vengono forniti nella forma opzione = valore Il le viene diviso in più sezioni delimitate da un nome tra parentesi quadre che deniscono una share (condivisione), oltre alla sezione generale [global]; Le righe di commento sono precedute da # o ;; I paramteri di congurazione possono estendersi su più righe di smb.conf utilizzando una backslash a ne riga; Le opzioni e i valori sono case insensitive, ma se si indica un path nel le system questo è case sensitive;

27 CAPITOLO 1. SAMBA NBNS Registration NB WORKGROUP<1d> BROWSER Browser Election Request NBNS Registration NB WORKGROUP<1d> BROWSER Request Announcement BROWSER Local Master Announcement SERVERSMB, Workstation, Server, Print Queue Server, Xenix Server, NT Workstation, NT Server, Master Browser BROWSER Domain/Workgroup Announcement WORKGROUP, NT Workstation, Domain Enum BROWSER Browser Election Request BROWSER Host Announcement PCXP, Workstation, Server, NT Workstation, Potential Browser Figura 1.12: Samba: Pacchetti TCP 1056 > netbios-ssn [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS= TCP netbios-ssn > 1056 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS= NBSS Session request, to SERVERSMB<20> from ACER-UV59QVXL7X<00> TCP netbios-ssn > 1056 [ACK] Seq=1 Ack=73 Win=5840 Len= NBSS Positive session response Figura 1.13: Pacchetti 68-72

28 CAPITOLO 1. SAMBA 27 Per separare una serie di valori possono essere usati sia virgole che spazi vuoti; Possono essere utilizzate delle variabili, precedute dal simbolo percento all'interno dei valori (es: path = /home/%u); Si può includere a smb.conf un altro le di congurazione con l'opzione include (es: include = /etc/samba/smb.conf.%a). Le opzioni di congurazione possono essere di due tipi fondamentali: global appaiono solo nella sezione [global] e deniscono i comportamente generali del server Samba share appaiono all'interno di speciche share e deniscono il comportamento riguardo alla specica share. Se appaiono in [global] deniscono i comportamenti di default per ogni share. Qualsiasi opzione deve essere inclusa in una sezione. sezioni speciali: Esistono le tre 1. [global] Sempre presente, di solito ad inizio le, denisce le opzioni di default valide per tutte le condivisioni (possono essere sovrascritte da opzioni presenti nelle speciche sezioni) e i parametri generali di congurazione del server 2. [printers] E' una sezione speciale utilizzata per condividere l'accesso via rete a delle stampanti 3. [homes] E' una sezione speciale che coincide con la home directory di un utente autenticato. Di fatto è una condivisione generica con il nome dell'utente che accede a Samba Oltre a queste sezioni speciali ne possono esistere altre, il nome di ogni sezione coincide con il nome della relativa condivisione, così come appare al client SMB. In gura 1.14 è illustrato un semplice esempio del principale le di congurazione di Samba smb.conf. La distribuzione utilizzata per l'esempio è Fedora core 2. Di seguito una breve spiegazione della congurazione della suite Samba relativa al sopracitato smb.conf: workgroup nome netbios del gruppo di lavoro server string nome netbios del pc su cui è installato Samba encrypt passwords indica a Samba di utilizzare password criptate indispensabile per l'utilizzo con win 98 e sucessivi

29 CAPITOLO 1. SAMBA 28 # 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

30 CAPITOLO 1. SAMBA 29 passwd program & chat programmi utilizzati per permettere agli utenti Windows di cambiare le loro password dai client. unix password sync Mantiene sincronismo tra le password unix e le password Windows. log le & max log size indicano la posizione e la dimensione massima dei le di log di Samba wins support tramite questo parametro Samba viene utilizzato per la risoluzione dei nomi wins. L'impostazione del parametro security merita una descrizione più approfondita. 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 parola d'ordine e nessun nominativo-utente. Samba tenta di dedurre il nominativo-utente dalla direttiva valid users eventualmente inserita nella sezione di condivisione di quella risorsa (come illustrato in seguito), oppure dal nome dell'elaboratore cliente, o, in caso di insuccesso, da quanto indicato con il parametro guest account (questo solo se fra i parametri di condivisione è indicato guest ok = yes e guest only = yes). Questo livello di sicurezza si usa, soprattutto nel caso di utenti MS- Windows e GNU/Linux non coincidenti, per condividere porzioni di le system quando si ha interesse a far sì che tutti gli utenti abbiano gli stessi diritti sui le condivisi (con l'impostazione guest account = utentesmb il proprietario delle risorse condivise sarà sempre l'utente GNU/Linux utentesmb qualunque sia il nominativo dell'utente MS- Windows che si connette). security = user Con questa impostazione, che è quella predenita, si ha il controllo di accesso a livello di utente: il client che vuole accedere a una risorsa invia al momento della connessione una coppia utenteparola d'ordine in base alla quale avviene l'autenticazione da parte del servente. Se la connessione viene accettata il cliente può accedere a tutte le risorse condivise senza doversi autenticare nuovamente a ogni accesso. Il controllo delle utenze viene eettuato dal server Samba in base al contenuto del le dei suoi utenti che solitamente è smbpasswd. Per gestire gli utenti Samba autorizzati ad accedere al server si utilizza il comando omonimo smbpasswd con il quale si posso aggiungere, cancellare utenti, cambiare loro la password.

31 CAPITOLO 1. SAMBA 30 È di fondamentale importanza notare che comunque il nome utente Samba deve coincidere con il nome di un utente denito nel sistema GNU/Linux, in quanto quest'ultimo deve essere sempre in grado di assegnare un proprietario valido agli eventuali le creati o copiati dall'utente connesso all'interno della risorsa condivisa. Se ciò non è possibile si può ricorrere all'uso di un le di corrispondenza tra utenti GNU/Linux e utenti MS-Windows, il cui nome è indicato con la direttiva username map. Un valore abbastanza comune di tale parametro è smbusers. Tale le conterrà delle righe così formate: nome_linux = nome_smb_1 nome_smb_2... Per ovvi motivi di sicurezza, entrambi i le smbusers e smbpasswd, devono essere accessibili sia in scrittura che in lettura dal solo utente root. Livello di sicurezza server security = server Con questa impostazione si ha lo stesso controllo di accesso visto nel caso di user con la dierenza che l'utenza viene controllata su un servente esterno (solitamente un PDC MS-Windows) il cui nome (NetBIOS) viene indicato con la direttiva password server. security = domain Con questa impostazione si ha ancora lo stesso controllo di accesso visto nel caso di user, ma questa volta il servente Samba va a inserirsi in un dominio MS-Windows NT/2000. Per aggiungere il server ad un dominio occorre fermare i demoni di Samba, quindi aggiungere il servente Samba al dominio NT sul PDC usando il server manager di MS-Windows NT oppure ad una active directory sul servente MS-Windows 2000 con la MMC (Microsoft Management Console) attraverso lo strumento Utenti e computer di Active Directory. A questo punto si deve eseguire il comando: smbpasswd -j nome_dominio -r nome_server -Unome_utente%parola_d'ordine Il nome_dominio deve essere lo stesso indicato nella direttiva workgroup di smb.conf, il nome_server deve coincidere con il valore di password server, nome_utente e relativa parola_d'ordine devono rappresentare un'utenza con privilegi sucienti ad aggiungere un'utenza nuova nella macchina MS-Windows NT/2000. Ultimate queste operazioni occorre naturalmente riavviare il servizio Samba. Il vantaggio principale dell'impostazione domain rispetto a quella server consiste nel fatto che il PDC risulta meno carico, in quanto non è più necessaria una connessione di rete permanente tra esso e il server Samba. Quest'ultimo infatti eettua una chiamata RPC solo al momento

32 CAPITOLO 1. SAMBA 31 stsamba:\ :mx=0:\ :sh:\ :sd=/var/spool/lpd/stsamba:\ :lp=/dev/null:\ :af=/var/spool/lpd/stsamba/acct:\ :if=/usr/bin/smbprint: Figura 1.15: smb.conf: uso stampante Windows con client Linux dell'autenticazione e non necessita di essere costantemente connesso al PDC come avviene nel caso del livello di sicurezza server. Per concludere occorre notare che comunque che questo tipo di impostazione (come nell'ipostazione server) è necessario tenere allineati gli elenchi degli utenti dal lato MS-Windows e dal lato GNU/Linux (il motivo è stato illustrato nel paragrafo del livello user). Ci sono però due direttive della sezione global che permettono di automatizzare l'aggiornamento degli utenti GNU/Linux: add user = script_1 %u delete user = script_2 %u La prima entra in azione quando, a seguito di una connessione di un cliente MS-Windows, Samba si rivolge al server di dominio per l'autenticazione con esito positivo ma l'utente GNU/Linux corrispondente non esiste, ovviamente lo script script_1 deve essere scritto in modo adeguato anché crei l'utente ricevendolo come parametro dalla variabile %u. In modo speculare si usa l'altra direttiva che entra in azione quando, a seguito di una connessione di un cliente MS-Windows, Samba si rivolge al server di dominio per l'autenticazione con esito negativo ma il corrispondente utente GNU/Linux esiste, in questo caso script_2 deve provvedere a cancellare l'utente in questione. Per usare su una macchina GNU/Linux una stampante condivisa da una macchina MS-Windows, occorre impostare in modo opportuno il le di denizione delle stampanti GNU/Linux: /etc/printcap. In gura 1.15 è illustato un esmpio di congurazione da aggiungere a smb.conf per consentire ad una stampante Windows di essere utilizzata da client Linux Il signicato dei parametri di congurazione elencati in g 1.15 è il seguente

33 CAPITOLO 1. SAMBA 32 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 nell'esempio è un ltro fornito in modo predenito con la distribuzione Red Hat all'interno del pacchetto samba-client. Anché il tutto funzioni è poi necessaria la presenza del le.cong nella directory della coda indicata con la riga sd=. Un esempio del suo contenuto è il seguente: share="//server_smb/nome_stampante_condivisa" user="tizio" password="password"\ 1.6 Applicazioni che costituiscono Samba La versione di Samba che viene presa in esame è la I pacchetti componenti la suite sono (si fa riferimento a pacchetti RPM essendo le prove state eettuate su macchine dotate di una distribuzione GNU/Linux fc2, x.y.z rappresenta il numero di versione): samba-x.y.z.i386.rpm contiene i demoni nmbd e smbd che sono alla base del funzionamento di un servente Samba e alcuni programmi di servizio come smbadduser, smbstatus; samba-client-x.y.z.i386.rpm contiene altri programmi di servizio come nmblookup, smbclient, smbmount, smbumount, smbtar, ndsmb, testparm; samba-common-x.y.z.i386.rpm nel pacchetto samba-common si trovano tra altri elementi il programma smbasswd e il le di congurazione di Samba /etc/samba/smb.conf precompilato con alcune impostazioni predenite. samba-swat-x.y.z.i386.rpm nel pacchetto samba-swat si trova l'utility SWAT (descritta in seguito) per la gestione e la condurazione dei demoni smb e nmbd tramite interfaccia graca

34 CAPITOLO 1. SAMBA 33 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 programmi ausiliari tra cui si ricoradano: smbclient smb client utility è una applicazione ftp-like per sistemi linux, usata per prelevare e inserire le da e nelle condivisioni Windows. Questa utility serve per mostrare il contenuto di una directory condivisa, inoltre può (nel caso di le testuali) eettuare la conversione end-of-line come nel caso dei trasferimenti text in ftp. smbclient può anche stampare su una stampante Windows condivisa, questo pacchetto è il cuore principale del lo script smbprint. smbclient non è un un utility userfriendly, al contrario è spesso utilizzata in altri script e chiamata da altre applicazioni come smbtar (utility per fare backup) e smbprint. smbfs I sistemi *nix possono supportare a livello di kernel il supporto per SMB File System, per accedere alle condivisioni di Windows. Un le sistem Windows può essere montato e utlizzato con metodologie simili a quelle applicate per lesystem NFS, ovviamente ci sono alcune significanti dierenze. NFS mantiene infatti sulle risorse condivise i permessi relativi agli utenti, al contrario smbfs non ha il concetto di permesso utente. La connessione ad una risorsa Windows avviene tramite un username e una password, che devo essere specicati all'istante della connessione. Il comando mount di linux non prevede la funzionalità aggiuntiva della specica di username e password. Samba fornisce un utility detta smbmount che permette di stabilire la connessione alla risorsa e montare il le system remoto. Smbmount crea anche un demone che provvede una automatica riconnessione alla risorsa nel caso di una perdita di connettività dovuta a un failvover della rete (il demone di controllo della connessione non era presente nelle prime versioni di Samba). SMB Wrapper Altro componente molto interessante della suite Samba è smbwrapper. Utilizzando questa libreria durante il link di un programma, le risorse condivise di Windows risultano accessibili con le normali librerie di funzioni open read close. La libreria smbwrapper è inclusa in molti programmi come ad esempio midnight commander. Un altro vantaggio di smbwrapper è che esso funziona su tutte le piattaforme *NIX, al contrario di smbfs che è tipico solamente di piattaforme unix. Lo svantaggio di smbwrapper è che le connessioni alle risorse non possono essere utilizzate da più processi contemporaneamente. Se due applicazioni hanno lo stesso le aperto questo richiede due sessioni con lo stesso le server, abbiamo così una diminuzione delle prestazioni poichè bisogna mantentere attive più connessioni contemporaneamente.

35 CAPITOLO 1. SAMBA 34 Figura 1.16: SWAT homepage SWAT Quando ci si appresta a congurare approfonditamente un server Samba ci si scontra inevitabilmente con la grande quantita di opzioni globali e di share. Ricordarsi un prospetto a mente può risultare scomodo e complicato, a questo scopo ci si può avvalere di un comodo tool graco di congurazione, Swat (Samba Web Administation Tool) che viene comunemente installato con il pacchetto samba-swat. Una volta eseguite una semplice congurazione dell'utility si può aprire il browser all'indirizzo: Si presenterà un nestra nella quale è necessario eettuare il login dell'account root. Come si può notare in g 1.16 si avrà immediatamente accesso ad una serie di menu che consentono di controllare varie opzioni tra cui share, utenti, parametri generali di congurazione del server Samba. Per ogni opzione si ha a disposizione un link ad alcune pagine di documentazione relative al comando selezionato. Attraverso SWAT è inoltre possibile acccedere ad una grande quantità di altra documentazione come manuali, man-pages, how-to.

36 CAPITOLO 1. SAMBA 35 Figura 1.17: SWAT wizard Va ricordato che nonostante sia possibile collegarsi anche da macchine remote, swat non ha di default la possibilità di usare password crittografate con conseguente pericolo di sning delle stesse. Esiste la possibilità di criptare le password anche se swat non lo supporta nativamente. Si può trovare un breve how-to introduttivo su [17]. Un'altro grande difetto di swat è che utilizzato su un le esistente ne modicherà anche il layout. Tutti i commenti eventualmente aggiunti e le opzioni include e copy verranno cancellati. Webmin Webmin e' un semplice tool web-based che permette, attraverso un interfaccia molto user-friendly, di poter amministrare praticamente l'intero sistema nix. E' anche un ottimo strumento didattico, in quanto permette di vericare la sintassi di le di congurazione e le funzionalità di servizi e programmi vari, editandoli tramite una intuitiva interfaccia graca. E' composto da un server web (che di default lavora sulla porta 10000) e da numerosi CGI scritti in Perl che agiscono direttamente su le di sistema come /etc/inetd.conf e /etc/passwd..

37 CAPITOLO 1. SAMBA 36 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, compreso il mac OS X. La sua natura modulare ha permesso la creazione di innumerevoli plug-in in grado di gestire e congurare diversi servizi. Tra questi plugin molto interessante è quello per la gestione della suite Samba visibile in gura Tramite questo tool si possono congurare una molteplicità di opzioni tra cui le share, il merge delgi utenti nix 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 utilizzarlo sotto altri ambiente come Gnome e Xfce). Smb4k fa uso della suite Samba per accedere alle risorse smb presenti sulla rete locale: è uno strumento completo e al contempo semplice da utilizzare. Al momento Smb4K supporta linux e FreeBsd (quest'ultimo in fase sperimentale). Tra le principali feature: possibilità di scansione workgroup (visibile in g 1.19), accesso ai le via Konqueror, operazioni di mount e umount attivabili tramite un semplice click, supporto delle condivisioni stampanti smb, possibilità di personalizzazione di username e passwdord per l'accesso alle share.

38 CAPITOLO 1. SAMBA 37 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 un protocollo basato su SMB, ma orientato verso Internet e mira ad aggiungersi ai 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 versioni di Windows abbastanza recenti hanno incluso una primitiva implementzione di CIFS. Le speciche sono aperte: l'intento è che diventino un RFC e vengano implementate su tutte le piattaforme, incluse quelle Microsoft e Unix. Sfortunatamente c'è ancora poca documentazione corretta e autorizzata a riguardo. Internet Al momento in cui il termine CIFS venne coniato la teconologia utilizzata da Microsft per le comunicazioni via rete era basata su protocolli netbios scarscamente applicabili a grandi reti. CIFS vuole dare una svolta a questa situazione ad esempio utilizzando per il servizio di naming DNS. File System CIFS permette la condivisione di directory, stampanti e le system tramite la rete internet.

39 CAPITOLO 1. SAMBA 38 I vantaggi dichiarati consisterebbero in un accesso multiplo in scrittura ai le senza perdita di integritàe coerenza, robustezza, buona velocità, sicurezza negli accessi, supporto dei caratteri in formato Unicode, uso di nomi con signicatività 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 specicha fornite da SNIA [19]. L'implementazione *nix più diusa di questo protocollo è CIFS VFS il cui sito uciale di riferimento è CIFS VFS è distribuito sotto licenza GNU GPL. Al contrario di altri lesystem di rete, CIFS e le relative impostazioni di autenticazione e autorizzazzione sono supportate e integrate a livello di kernel. Linux-CIFS è infatti stato approvato dagli sviluppatori del Kernel Linux già dalla versione Le attuali implementazioni di CIFS non orono supporto per vecchie installazioni di le server SMB, motivo per cui all'interno di uno stesso sistema possono coesistere versioni dierenti di SMB e CIFS.

40 Capitolo 2 Netatalk 2.1 Introduzione Uno dei grandi vantaggi di Macintosh rispetto ai normali PC è la disponibilità su ogni macchina di software e hardware di rete, per scambiare dati tra calcolatori, presenti n dalle prime versioni di tale sistema operativo. Tutti i Macintosh, vengono dotati di serie dell'elettronica necessaria per scambiare dati da macchina a macchina. Il sistema operativo Mac OS, dalla versione 7.0 in poi, e consente di condividere applicazioni e documenti con grande facilità tramite l'utilizzo di una rete detta AppleTalk. AppleTalk fu sviluppato nei primi anni 80 dai laboratori Apple. E' uno standard proprietario per l'interconnessione tramite rete di elaboratori Machintosh. AppleTalk specica uno stack protocollare che consente di dirigere e organizzare il usso di dati attraverso una rete. Apple Computer usa il nome AppleTalk per riferirsi a Apple Network Protocol Architecture. Lo standard AppleTalk seppur prorpietario venne presto pubblicato e pubblicizzato per consentirne implementazione e sviluppo sotto altre piattaforme. AppleTalk è implementato sotto una molteplicità di sistemi operativi: OSX Server, AppleShare server,windows Server, *nix, BSD e altri ancora. Linux fornisce supporto completo per le reti AppleTalk tramite una suite chiamata Netatalk. Netatalk è l'implementazione a livello kernel dell'appletalk Protocol Suite, derivata da sistemi BSD. Include il supporto per l'instradamento AppleTalk, la condivisione di lesystem Unix e AFS su AFP (Apple lling protocol), la condivisione di stampanti Unix e l'accesso a stampanti AppleTalk tramite PAP, tutti concetti che saranno descritti sucessivamente nel dettaglio. 2.2 AppleTalk e lo standard ISO/OSI In questa sezione verrà fornita una breve descrizione dei componeti del protocollo AppleTalk. L'architettura AppleTalk consiste in un certo numero 39

41 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 serie di regole, e sono implementati in maniera dierente a seconda della specica piattaforma. Di seguito si da una descrizione dei vari protocolli AppleTalk suddividendoli in base al livello ISO/OSI di appartenenza. Presentation/Application Layer I livelli di presentazione/applicazione assumono che una connessione host-to-host si sia già instaurata e si preoccupa della sintassi utilizzata per il trasferimento dei dati. Nel modello ISO/OSI AFP implementa sia livello di presentazione che il livello applicativo. AFP Il protocooloapple Filling Protocol permette ad una Workstation presente su una AppleTalk network di accedere ai le presenti su un Server AppleShare. Grazie ad AFP i le presenti sul disco di un server remoto appaiono alle applicazioni e agli utenti come se fossero sul disco locale. Come si può notare in gura 2.3 un programma in esecuzione locale su di una workstation esegue operazioni sui le usando i comandi nativi del lesystem. Tramite AFP è possibile usare gli stessi comandi del lesystem nativo anche per modicare risorse residenti su server remoti. Sempre in gura 2.3, si nota che un programma in esecuzione invia dei comandi al lesystem nativo del sistema. Una struttura dati memorizzata in memoria centrale indica se le porzioni di lesystem che interessano le operazioni sono locali o residenti su di un server remoto, nel secondo caso le richieste vengono inoltrate ad un AFP translator che le traduce in richieste AFP e le inoltra in remoto a sua volta. Le eventuali implementazioni di AFP in ascolto sul no-

42 CAPITOLO 2. NETATALK 41 Figura 2.2: AppleTalk Protocol Stack do remoto devono essere capaci di tradurre richieste ai le system nativi 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 la struttura del le system remoto. 3. Algoritmi associati con i comandi che specicano la azioni eseguite dai comandi. 4. Un sistema di autenticazione a livello utente. Un le server è generalmente un computer con una grande capacità di memorizzazione utilizzato per condividere risorse sulla rete. Esso è identicato da un nome univoco e da altri parametri essenziali tra cui : desrizione, numero dei volumi contenuti, versione del protocollo AFP utilizzato. Un volume è una condivisione resa disponibile sulla rete AppleTalk tramite un leserver AFP. Ciascun le server può condividere più di un volume, abbinando a ciascuno di essi determinati parametri tra cui: attributi del Volume (nome del volume, possibilità di memorizzare nome utente e password per limitare l'accesso alla risorse, data di creazione, data di ultima modica). Il protocollo AFP al contrario dei altri protocolli di rete come SMB o NFS si riferisce principalmente alle condivisioni (le e directory) tramite un identicativo ID e non tramite un percorso. Esistono principalmente due tipi di volumi implementati da AFP:

43 CAPITOLO 2. NETATALK 42 Figura 2.3: Struttura di una chiamata AFP Fixed Directory ID La struttura gerarchica di questo tipo di volume è composta da directory e sottodirectory, ciascuna delle quali contiene un identicativo univoco all'interno del volume. L'ID viene assegnato alla creazione della directory stessa. Anche se la directory viene cancellata l'id che le era stato associato rimane non disponibile. Variable Directory ID Anche questa struttura gerarchica mantiene un univocità di ID all'interno del volume associato ad una directory ma al contratrio del caso precedente l'id è creato quando il server AFP manda un comando FPOpenDir (per accedere alla directory). L'ID viene cancellato quando viene eseguito un comando FPCloseDir, in seguito al quale l'id è nuovamente disponibile per altre directory. Il Variabale Direcory Id non è più utilizzato e non è supportato dalle ultime versioni del protocollo AFP. Il Volume Catalog, di cui è fornito un esempio in g 2.4, serve per associare a ciascuna entità di un volume (le o directory) l'identicativo univoco corrispondente. La struttura di un Volume Catalog deve rispettare le seguenti regole: i nodi terminali di una struttura ad albero possono essere directory vuote o le. i nodi interni possono essere solo directory, le quali instaurano relazioni di parentela con altri nodi (ad esempio Parent of, Ospring of, ecc...). All'interno di una struttura di Volume Catalog, anche il nome CNode (Catalog Node: nome del nodo all'interno del catalogo) identica univocamente il le o la directory che interessa.

44 CAPITOLO 2. NETATALK 43 Figura 2.4: Struttura Volume Catalog Con l'introduzione della versione 3 dell' AFProtocol ora tutte le versione dei recenti sistemi operativo Apple sono in grado di riconoscere i caratteri UNICODE codicati nel formato UTF8 per quel che riguarda i nomi dei le 1. Per compatibilità con le versioni passate di Mac OS Netatalk supporta anche i vecchi tipi di formato carattere tra cui il più diuso, utilizzato nella maggioranza dei paesi occidentali è il MAC_ROMAN. Per eettuare ciascuna operazione sui CNode ad essi deve essere associato un percorso (chiamato pathname) per poterli raggiungere. A ciascuna entità del Catalog Volume possono essere associati più pathname, poichè dipendono dal punto iniziale di partenza. Per ottenere questo risultato AFP utlizza la struttura visibile in gura 2.5. Il pathname associato a ciscuna entità è una stringa Pascal dove nei primi byte è indicata la lunghezza totale della stringa stessa. Session Layer Il livello di sessione fornisce un'interfaccia per l'accesso al livello di trasporto sottostante. Il livello di sessione si preoccupa di stabilire una connessione (detta sessione) sulla quale si basa il dialogo 1 UTF8 è un sistema di encoding dei caratteri Unicode. UTF8 associa a ciascun carattere unicode un insieme (da 1 a 4) di ottetti di caratteri. Per maggiori informazioni visitare [23]

45 CAPITOLO 2. NETATALK 44 Figura 2.5: CNode tra due applicazioni. Le principali funzioni fornite dal livello di sessione sono controllo di usso, ssaggio di punti di recupero sincronizzazione per verica e recovery di le transfer. I protocolli Apple Talk situati al livello di sessione sono: ZIP The Zone Information Protocol. AppleTalk Networking è basato sul concetto di zona, la quale indica un area logica che include gruppi di utenti e risorse. Una zona può estendersi attraverso reti multiple (piu network possono formare un unica zona). I router separano le zone e un insieme di zone è chiamato internet 2. Le zone rendono più semplice l'individuazione da parte dell'utente dei servizi disponibili. Ad esempio un certo utente piuttosto che visulizzare tutti gli utenti o le risorse di una rete può visualizzare solo quelle della zona di appartenenza. Il concetto di zona è simile al concetto di Workgroup introdotto da Microsoft. Tutti gli host collegati a reti AppleTalk utilizzano un indirizzo composto da 2 parti: Network Number e Node Number. Zip Protocol: fornisce alle applicazioni e ai processi accessi alle zone identicandole in base ai nomi. Le principali tipologie di frame ZIP sono: zonename query / reply: Richiede / fornisce il nome di zona associato ad un dato numero di rete. zonelist query / reply: Richiede o fornisce l'enlenco completo della lista delle zone attive e raggiungibili. get zone reqst/reply: Richiede / fornisce l'identicativo associato alla zona corrente take down / bring up zone: Elimina o inserisce una zona all'interno della zone list. All'interno dei frame ZIP vengono utilizzati i seguenti parametri principali: Number: numero della rete da utilizzare in frame zonelist query / reply Zone Name: nome associato alla zona Default Zone: nome della zona corrente. 2 Durante tutto il capitolo con il termine internet verrà indicato un insieme di zone, non la rete geograca mondiale.

46 CAPITOLO 2. NETATALK 45 Take down / Bring up zone: elimina o inserisce una zona all'interno della zone list l'elenco delle zone attive. ASP AppleTalk Session Protocol imposta e mantiene una sessione tra una workstation e il server. ASP è un protocollo asimmetrico nel quale ad un lato della conversazione il client ASP della workstation inizia la comunicazione che verrà sfruttata dalle applicazioni di livello superiore. ASP fornisce anche un meccanismo tramite il quale il server può mandare un messaggio alle workstation (per esempio in fase di connessione al server o spegnimento di quest'ultimo). ASP è usato da AFP per permettere ad un utente di manipolare i le presenti sul le server. I principali frame utilizzati da ASP sono: open / close session request: richiesta di apertura e chiusura di una sessione ASP; command call request / reply: chiamata ad / ripsosta da un protocollo di livello superiore; status request / server status reply: richiesta / risposta sullo stato del server; take down / bring up zone: elimina o inserisce una zona all'interno della zone list; write continue req: Cominicia o continua il trasferimeto per la scrittura dei dati; write continue reply: conferma la possibilità di continuare o iniziare a scrivere dati. All'interno dei frame sopra indicati sono utilizzati i seguenti parametri Session ID: codice utilizzato per identicare sessione; Sequence Number: utilizzato dai comandi write continue per mantenre ordine dei dati; Server session socket: l'identicativo della Socket usata durante la sessione; Versione Number: numero di versione ASP correntemente in uso; Buer Size : massima direzione in byte del buer in uso; Write continue reply: conferma la possibilità di continuare o iniziare a scrivere dati. ADSP AppleTalk Data Stream Protocol (ADSP) è un protocollo connectionoriented tramite i quali i programmi che fanno uso di socket possono scambiare dati. Oltre ad essere connection oriented gestisce il ow control e controlla l'ordine dei dati ricevuti. ADSP è un protocollo simmetrico, i socket client ai lati della connessione possono avere uguale controllo sui dati scambiati (al contrario di ASP) Alcuni dei frame ADSP sono i seguenti:

47 CAPITOLO 2. NETATALK 46 acknowledge/probe: fornisce acknowledge per i dati inviati o lo richiede; open / close connect reqst: richiede l'inizio o la ne di una sessione ADSP; retransmit advise: chiede di reinviare i dati. I principali parametri contenuti nei frame ASP sono: Source Connection Id: codice utilizzato per identicare il mittente di una connessione; Destination Connection Id: codice utilizzato per identicare il destinatario di una connessione; Send Sequence Number: numero di sequenza utilizzato per lo stream di dati in uscita; Receive Sequence Number: numero di sequenza utilizzato per lo stream di dati in ingresso; Version: numero di versione in uso. Transport Level Il livello di trasporto isola alcuni degli aspetti sici e funzionali tipici di una rete a pacchetti dai tre livelli sovrastanti. Si occupa di una gestione della connessione end-to-end, preoccupandosi anche della gestione della avvenuta ricezione dei dati rispettandone l'ordine. Il livello di trasporto implementa quindi una consegna af- dabile dei dati implementando meccanismi per l'identicazione degli eventuali pacchetti persi e fornendo un meccanismo di buerizzazione e ritrasmissione. Appletalk fornisce le seguenti implementazioni per questo livello: Name Binding Protocol NBP fornisce a processi e applicazioni un sistema per mappare i nomi delle risorse utilizzabili dalle persone con numeri utilizzati dai computer. Quando un'applicazione è avviata ad essa viene associato un nome, che viene utilizzato da altre applicazioni per rintracciarla. Quando l'applicazione termina viene cancellata l'entry corrsipondente all'associazione nome applicazione. Tutte le applicazioni e i processi che usano una rete AppleTalk fanno anche uso di NBP per rendere disponibili sulla internet AppleTalk i servizi oerti. Un applicazione o un processo può utilizzare NBP per: registrare se stesso con NBP, associando un nome composto da 3 parti con la socket corrispondente; controllare una nuova entry NBP corrispondente ad una nuova applicazione; rimuovere la propria entry dalla tabella NBP quando non la ritiene più util.

48 CAPITOLO 2. NETATALK 47 Routing Table Maintenance RTMP serve per memorizzare le informazioni sul routing necessarie per le internet AppleTalk. RTMP comunica i numeri di network conosciuti e dati riguardanti l'accessibilità, nonchè le vie per raggiungere le varie zone interconnesse. L'implementazione RTMP su di un AppleTalk router mantiene una tabella, chiamata routing table, che specica il più breve percorso possibile per raggiungere una rete. AppleTalk Transaction Protocol ATP permette ad una socket di trasmettere una richiesta di esecuzione di una determinata operazione ad un'altra socket e di riceverne la relativa risposta. ATP fornisce un adabile sistema di consegna di pacchetti gestendo le ritrasmissioni di eventuali pacchetti persi e garantendo la conservazione della giusta sequenza di messaggi. Il protocollo ATP permette 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 processo clienti che sfrutta il protocollo DDP (si veda nel seguito). Il processo in questione chiamato AEP Echoer, usa una socket speciale per l'ascolto dei pacchetti trasmessi dalle socket client sugli altri nodi della rete. Quando riceve un pacchetto, l'aep Echoer lo ritrasmette direttamente al mittente. I pacchetti AEP possono essere utilizzati per testare se un nodo è raggiungibile e qual'è la distanza che bisogna coprire (rilevata in numero di hop da attraversare). Network layer Il Livello di rete specica l'instradamento dei pacchetti dati tra i nodi e gestisce le comunicazioni tra reti dierenti (internetworking). A livello di rete la suite AppleTalk implemente il protocollo DDP e AARP, come di seguito spiegato: DDP Il Datagram Delivery Protocol è un protocollo connectionless che fornisce un servizio di tipo best-eort. Questo signica che il protocollo DDP non include supporto per assicurare che tutti i pacchetti siano eetivamente arrivati a destinazione e nella giusta sequenza. Di questo si occupano eventualmente i protocolli di livello superiore. La rete AppleTalk può funzionare con vari tipi di collegamenti sici dierenti: LocalTalk e è disponibile sui calcolatori Machintosh più vecchi. Per eettuare un collegamento LocalTalk si usa la porta stampante del Macintosh. LocalTalk è una connessione relativamente lenta (230 Kbits/s) ed ormai in disuso.

49 CAPITOLO 2. NETATALK 48 Figura 2.6: Struttura Frame AARP TokenTalk AppleTalk sul link sico TockenRing. Siccome nessun Mac è dotato di default delle interfacce necessaria per usare questo tipo di connessione, TokenTalk si usa solo in casi speciali: per esempio per collegare i Mac ai vecchi calcolatori IBM, che fanno spesso uso della rete TokenRing. EtherTalk é l'implemetazione della rete Netatalk su link sico ethernet. questo tipologia è sicuramente la più diusa e la più utilizzata al giorno d'oggi grazie a caratteristiche di adabilità e del costo limitato dei supporti sici. AARP AppleTalk Address Resolution Protocol è usato per mappare l'indirizzo dei nodi utilizzato dal protocollo DDP e l'indirizzo del livello data link sottostante che fornisce la connettività. La struttura del pacchetto Arp è, come indicato in gura 2.6, composta da: Hardware type: Identicatore per il tipo di data-link; Protocol Type: Identicatore per il tipo di protocollo; Hardware Address Lenght: Lunghezza in byte del campo HArdware Address; Protocol Address Lenght: Lunghezza in byte del campo Protocol Address; Function: Indica il tipo di funzione del pacchetto AARP: 1 richiesta, 2 risposta, 3 test. Data-Link and Physical Layers: Questi due livelli forniscono la connettività. Questi due livelli sono composti dal mezzo trasmissivo utilizzato (doppino, cavo coassiale), dalle periferiche usate per interfacciare i mac al mezzo trasmissivo, dai driver per pilotare le periferiche.

50 CAPITOLO 2. NETATALK Una implementazione del protocollo Appletalk Linux fornisce supporto completo per le reti AppleTalk. Netatalk è l'implementazione a livello kernel dell'appletalk Protocol Suite, derivata da sistemi BSD. Include il supporto per l'instradamento AppleTalk, la condivisione di lesystem Unix e AFS su AFP (Apple lling protocol), la condivisione di stampanti Unix e l'accesso a stampanti AppleTalk tramite PAP, tutti concetti che saranno descritti sucessivamente nel dettaglio. Fin dalla versione di Mac OS 8.5 Apple fornisce una completa implementazione del protocollo di trasporto Tcp/Ip. Unita all'implementazione del Tcp/Ip vi è la modica del protocollo AFP (Apple Filling Protocol) che ora è incapsulabile all'interno di pacchetti Tcp. Mediante l'utilizzo di Netatalk si può integrare il lesystem Linux all'interno dei sistemi Mac. Con Netatalk si possono addirittura eseguire processi di stampa sulle stampanti Linux e condividere altre risorse. Netatalk è sofware open-source e consente di trasformare una macchina *nix in un potente ed adabile le server Linux per reti Machintosh. Il progetto in origine era sviluppato da un gruppo di ricerca dell'universita del Michigan [25], dopo un periodo di inattività è diventato un prodotto opensource sviluppato da volontari [22]. Usando i servizi di le server Netatalk 2.0 compatibile con AFP 3.1 (l'ultima versione del protocollo di trasporto Macintosh) si ottengono velocità di trasferimento molto maggiori comparate con l'utilizzo su Mac OS di trasferimenti SMB/NFS[21]. Inoltre Netatalk fornisce supporto per trasferimenti con protocolli AFP compatibili anche con vecchie versioni di Mac OS (ad es 8 e 9) i quali non incorporano gli strumenti per l'accesso a reti SMB. Con Netatalk è possibile accedere a stampanti che supportano il protocollo AppleTalk. Dalla versione 2.0, Netatalk è compatibile con CUPS il sistema di stampa più utilizzato in ambito *nix. Netatalk può anche essere utilizzato come AppleTalk router per suddividere la rete Mac in dierenti zone. 2.3 Compilazione e installazione di Netatalk In questo paragrafo viene descritta e analizzata la procedura antecedente l'utilizzo di Netatalk. Il pacchetto software Netatalk ha bisogno di librerie software 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 Questa versione è disponibile solo 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 Netatalk è utilizzabile con molti sistemi operativi *nix, FreeBsd e Solaris. Gcc Per la compilazione di Netatalk è necessario gcc versione o su-

51 CAPITOLO 2. NETATALK 50 periori. Per essere compilato con il supporto per AFP 3.1 deve essere attivato 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 robusto scalabile per la gestione dei dati. Viene attualmente utilizzato da grandi realtà come Cisco System, Motorola, Alcatel, Sendmail Inc. Berkley Db è un prodotto freeware e ope-source ma contiene alcune particolari condizioni per quanto riguarda soluzioni a pagamento e closed-source. Berkley Db è denito embedded poichè è collegato direttamente all'applicazione e lavora nel suo stesso spazio di memoria (non necessita di meccaniscmi IPC Inter-Process Communications per la gestione delle comunicazioni tra processi). Può esere collegato ad una applicazione standalone o a più applicazioni che cooperano. Caratteristica molto importante per la cooperazione con Netalk, Berkley Db ha un ottima gestione 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. OpenSSL permette di implementare il protocollo SSL V2/V3 (Secure Sockets Layer) e il protocollo TLS V1 (Transport Layer Security) e consiste in un insieme di librerie per uso generale utilizzabili da terzi programmi (come ad esempio Netatalk, Apache). E' un progetto interamente sviluppato da volontari e si basa sulle librerie SSLeay [26] sviluppate da Eric A. Young e Tim J. Hudson. OpenSlp Slp (Service Location Protocol) è un protocollo sviluppato originalmente dall' IETF 3 che fornisce un supporto alle applicazioni di rete per la scoperta dell'esistenza e della localizzazione e la congurazione di eventuali servizi presenti su una medesima rete. Esistono altri protocolli di localizzazione su rete (si pensi ad esempio al protocollo SMB) ma prima dell'avvento di Slp nessun protocollo di localizzazione fu standardizzato da IETF. Poichè non è un protocollo proprietario ha avuto grande svilupo in ambiente *nix [27]. Dopo aver installato e congurato i software sopracitati è necessario procedere alla compilazione dei sorgenti. 2.4 Congurazione di Netatalk In questa sezione verrà analizzato il comportamento dei vari componenti della suite Netatalk, utilizzando inoltre un esempio di congurazione. 3 La Internet Engineering Task Force è una comunità aperta di tecnici, specialisti e ricercatori interessati all'evoluzione tecnica e tecnologica di Internet.

52 CAPITOLO 2. NETATALK 51 Figura 2.7: AppleTalk Protocol Stack I le di congurazione di Netatalk si trovano solitamente nel percorso /usr/local/etc/netatalk I demoni del programma sono molteplici e a ciascuno di essi è assegnata una funzione specica: 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 *nix di 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ò notare in g2.7. I protocolli ATP e ASP sono implementati come librerie esterne Congurazione di AppleTalk Routing Il le atalkd.conf è utilizzato dal demone atalkd per impostare le interfacce AppleTalk congurandone o meno il routing. Per fare in modo che i router AppleTalk instradino correttamente il traco, è necessario che identichino correttamente ciascun segmento di rete. Nel caso di reti Ethertalk, l'identità della rete è stabilita in base ad un Network Number. Per ciascun segmento di rete collegato al meno un router deve fornire il Network Number che identica univocamente il segmento. Il più semplice metodo per utilizzare Netatalk è non usufruire del servizio di AppleTalk routing. Questa congurazione va usata nel caso in cui si abbia una sola interfaccia di rete. Netatalk è così in grado automaticamente di impostare l'interfaccia per utilizzare un indirizzo AppleTalk e registrarlo sulla rete. Il nome delle zone sono collegati ai segmenti di rete, ma non vi è corrispondenza biunivoca. Una zona può infatti estendersi su più network dierenti oltrepassando i router, ad esempio per unire gruppi logici di utenti.

53 CAPITOLO 2. NETATALK 52 eth0 -dontroute -phase 2 -net addr Figura 2.8: atalkd.conf: routing disabilitato, 1 interfaccia rete (eth0) eth0 -dontroute -phase 2 -net addr eth1 -dontroute -phase 2 -net addr Figura 2.9: atalkd.conf: routing disabilitato, due interfacce di rete (eth0 eth1) AppleTalkRouting disabilitato Nel caso di interfaccia singola si può decidere se lasciare il le atalkd.conf completamente vuoto o utilizzare equivalentemente una sintassi visibile in gura 2.8 grazie alla quale Netatalk viene impostato per utilizzare l'interfaccia eth0 e il protocollo fase 2. Il parametro -net indica che non si è in presenza di AppleTalk router. Successivamente viene specicato quindi un numero di rete pari a e un numero di nodo pari a 166 Numeri di rete compresi nell'intervallo e numeri di nodi tra fanno parte dello startup range range all'interno del quale atalkd seleziona un indirizzo se congurato in modo automatico senza AppleTalk router. Nel caso di utilizzo di più interfacce di rete si può utilizzare la congurazione indicata in gura2.9, con il parametro -dontroute, si informa il demone atalkd di non utilizzare il routing all'interno della rete AppleTalk. AppleTalkRouting abilitato Esistono 3 tipi dierenti di router AppleTalk, elencati di seguito: Seed: iene congurato con un network number e un nome di zona che identica il segmento di rete a cui è collegato. Ogni segmento su di una extended network di rete ha almeno un seed-router da cui i client collegati prendono informazioni. Possono esserci più seed router collegati ma non devono contenere informazioni dierenti in contrasto gli uni con gli altri; Non seed: è un router congurato in modo da ricevere informazioni da un seed router che è connesso alla sua stessa rete. Questo tipo di funzionamento non necessita di alcuna congurazione manuale; Soft-seed: il funzionamento è identico a quello di un Non-Seed Router, oltre a cui si aggiunge la capacità di funzionare come un Seed Router nel caso in cui il seed router sia momentaneamente fuori uso;

54 CAPITOLO 2. NETATALK 53 eth0 -seed -phase 2 -net addr zone "Printers" -zone "Spoolers" eth1 -seed -phase 2 -net addr zone "Macs" -zone "Servers" eth0 eth1 Figura 2.10: atalkd.conf: seed router Figura 2.11: atalkd.conf: soft-seed router Il demone atalkd è in grado di funzionare sia come seed che come soft-seed router. Per impostare atalkd come seed router è necessario fornire 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, fortunatamente atalkd di utilizzare una certa congurazione verica prima la possibile esistenza di conitti sul network. I possibili netrange utilizzabili, in un network con router, vanno da 1 a per far si che non siano sovrapposti con eventuali subnet collegate per le quali è stata usata un impostazione automatica di atalkd. Utilizzando il protocollo AppleTalk fase 2 l'indirizzo di rete consiste in una parte 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 aiutare l'organizzazione logica delle risorse. Possono esistere network con più zone al loro interno oppure zone che si estendono su più network. Per congurare atalkd per l'utilizzo come AppleTalk router bisogna settare le opzioni visibili in gura Se il comando -net viene omesso allora viene utilizzato come numero di sottorete quello corrispondente all'indirizzo assegnato all'interfaccia del server Netatalk. L'opzione -zone può apparire più di una volta su una stessa riga poichè ad un determinato segmento possono essere associate più zone. In gura 2.11 è presente una semplice esempio di atalkd.conf utilizzabile per congurare il demone associato come soft-seed router supponendo che sia presente un seed-router che fornisca le informazioni autoritative per quel segmento di rete.

55 CAPITOLO 2. NETATALK 54 "Server Netatalk" -ipaddr 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) Congurazione di un File Server AFP è il protocollo utilizzato dai Machintosh per le service attraverso reti AppleTalk. afpd.conf afpd.conf è il le usato per determinare il comportamento dei le-server virtuali gestititi da Netatalk. Gli utenti usati nelle sessioni di AppleTalk networking coincidono con gli utenti del sistema *nix. Nell'esempio di gura 2.12 il le afpd.conf è congurato per attivare un unico le server dal nome Server Netatalk, indirizzo ip e messaggio di benvenuto indicato con la stringa -loginmesg AppleVolumes.default Questo le viene utilizzato per denire le share che di default vengono automaticamente mostrate a tutti gli utenti. Per limitare l'accesso ad alcune share agli utenti si possono utilizzare i ag deny e allow. Nell'esempio riportato in gura 2.13 vengono attivati due Vuolumi: Corrisponde alla condivisione delle Home degli utenti, è l'impostazione predenita del server Netatalk conclusa l'installazione. /public La seconda condivisione indica una share pubblica corrispondente al mount point /public sul server Netatalk identicata dalla stringa Cartella Pubblica. Per questa cartella viene utilizzata il formato caratteri CNode ID backends Come già visto il funzionamento del protocollo AFP è basato sulla struttura del Catalog Volume e degli ID univoci assegnati alle risorse contenute nel volume. Per consentire una corretta associazione tra gli ID utilizzati da AFP e gli elementi del lesystem *nix Netatalk utilizza una struttura

56 CAPITOLO 2. NETATALK 55 database. Le strutture database che è possibile utilizzare sono specicate nel le AppleVolumes.default. Il backend più utilizzato, specicato con l'opzione cnidscheme:cdb nel le AppleVolumes.default è concurrent database basato sulle librerie Berkley Db fornite da Sleepycat [24]. Il database viene memorizzato nei le.appledb di ogni cartella del Volume AFP. Lavorare con un database comporta qualche complicazione, ad esempio non è possibile fermare i processi Netatalk improvvisamente poichè si rischia di corrompere il database BerkleyDb. Autenticazione tramite protocollo AFP Apple ha scelto per il protocollo AFP un modello fessibile di autenticazione chiamato User Autentication Modules (UAM). Un client AFP inizialmente si connette ad un server il quale fornisce una lista dei moduli UAM disponibili scegliendo tra questi quello con caratteristiche di sicurezza maggiori. I principali metodi di autenticazione UAM sono: No User Autenth E' utilizzato dagli utenti che eseguono login come ospiti sulla macchina. ClearText Password La coppia username-password è inviata lungo il network sotto forma di stringa non cifrata. Il parametro UserAuthInfo utilizzato da AFP consiste in un username (una stringa di massimo 255 caratteri) e una password (di massimo 8 byte). La comparazione dello username è case-insensitive, la password è confrontata in modo case-sensitive. Se esiste un utente corrispondente a quello inviato nella stringa UserAuthInfo si passa sucessivamente alla comparazione della password. Se qualcosa non funziona (utente non esistente o password errata) nel processo di autenticazione viene inviato un codice di errore al client. Random Number Exchange E' utilizzato in caso di rete non sicura dove è possibile uno sning delle password. Con questa tecnica il processo di autenticazione è suddiviso in più fasi, come prima cosa il client invia al server il nome utente (inviato in caratteri non criptati lungo il network). Nel caso in cui l'username non sia valido il server risponde con un messaggio di errore. Se l'username inviato esiste nel database del server allora il processo di autenticazione procede: il server genera e invia un numero random a 8 byte e lo invia al client. Sia il client che il server utilizzano il protocollo DES 4. Il testo cifrato viene costruito sia sul client che sul server. Il client invia al server la frase cifrata 4 Data Encryption Standard: sviluppato inizialmente nel 1977 è un algoritmo di crittograa che si di una chiave di 56 byte (in questo caso la password dell'utente) che assieme al testo in chiaro (64 bit ovvero 8 byte il numero random generato) forniscono un testo cifrato a 8 byte anch'esso [29].

57 CAPITOLO 2. NETATALK 56 e sucessivamente il server la confronta con quella costruita. Se le due frasi 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 di un secondo numero random di 8 byte per l'autenticazione del server da parte del client. Entrami i metodi Random Exchange non orono alti livelli di sicurezza a causa dell'utilizzo dell'algoritmo DES. Die-Hellman Exchange E' un'implementazione del Die-Hellman Key Agreement Protocol using the SSLeay/OpenSSL [30] il cui nome UAM è DHCAST128. E' più robusto dei precendenti sistemi di crittograa rispetto ad attacchi di forza bruta, ma non è indenne da attacchi del tipo Man In the Middle, il client infatti non ha possibilità di vericare l'autenticità del server. Tramite DHX sia il client che il server generano un numero Ra e Rb utilizzati come chiavi private. Entrambe le parti usano il modulus exponentation per derivare le chiavi pubbliche (Ma e Mb) che vengono sucessivamente scambiate. Sucessivamente il client utilizzando Ra e Mb crea una chiave si sessione k, anche il server a sua volta usando Ma e Rb crea una chiave di sessione k identica. La fase seguente è detta di verica della chiave k, ciascun processo (client e server) crea un numero random (chiamato nonce) lo codica utilizzando come chiave k, e lo invia all'altro processo. Entrambi modicano il valore scambiato con un algoritmo noto (per esempio incrementandone il valore) e riscambiano i valori per vericare se tutto è avvenuto correttamente. I metodi di autenticazione elencati nora sono stati creati dagli sviluppatori Apple. Esistono altri possibili metodi di autenticazioni creati da sviluppatori di terze parti tra i quali spiccano: PGPuam 1.0 UAM basato su algoritmo PGP. Per poter essere utilizato con Netatalk bisogna compilare i sorgenti con opzione enable-pgp-uam [28]. Kerberos IV - AFS Kerberos Consente l'utilizzo di autenticazione Kerberos versione 4. Per poterlo utilizzare bisogna compilare netatalk con l'opzione enable-krb4-uam Per scegliere il protocollo di autenticazione supportato dal server Netatalk è necessario utilizzare l'opzione AFPD_UAMLIST presente all'interno del le netatalk.conf. Per quello che riguarda la scelta del protocollo di autenticazione utilizzato si dovrebbe far riferimento alle seguenti considerazioni: 1. Evitare No User Authent, poichè può consentire un accesso accidentale e non autorizzato alle risorse. Per avere share pubbliche utilizzare i parametri di accesso congurabili in AppleVolumes.default.

58 CAPITOLO 2. NETATALK Il metodo ClearTxt Passwrd non è indicato in quanto vi è possibilità di sning dei parametri per autenticazione al server. 3. Randonum exchange e il suo derivato vanno evitati poichè utilizzano il protocollo DES e chiavi a soli 56 bit. Inoltre non è possibile integrare questa autenticazione all'interno del sistema di autenticazione *nix (sia /etc/shadow sia PAM ), è necessario memorizzare le password in chiaro sul server e gestirle tramite il comando afppasswod. 4. DHCAST128 sembra essere attualmente il miglior compromesso poichè combina una forte crittograa dei dati ed è integrabile com metodi di autenticazione tipo PAM o /etc/shadow netatalk.conf netatalk.conf è il principale le di congurazione della suite Netatalk. La sua struttura è riportata in gura 2.14 AFPD_MAX_CLIENTS numero massimo di client che possono accedere contemporaneamente al server; ATALK_NAME congura il nome del server AppleTalk ATALK_MAC_CHARSET specica il set di caratteri utilizzato sul Mac; ATALK_UNIX_CHARSET specica il set di carattere utilizzato sul server; AFPD_UAMLIST lista degli algoritmi di criptazione utilizzati; AFPD_GUEST utente *nix corrispondente all'utente guest netatalk; Principali Utility di Netatalk In questa sezione vengono analizzate le principali utility che possono essere utlizzate con Netatalk: aecho AppleTalk Echo Utility. Spedisce pacchetti AppleTalk Echo Protocol agli host della rete. Come opzioni possono essere specicate il numero di pacchetti da inviare e gli host della rete a cui inviarli (indicati con indirizzo Appletalk o nome NBP) getzones Fornisce un listato contentente i nomi delle zone AppleTalk. Si può specicare 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, MacBinary, AppleSingle (formati usati da precedenti versioni di MacOS per scambiare dati), AppleDouble (formato usato dall'implementazione netatlk di afpd).

59 CAPITOLO 2. NETATALK 58 # 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

60 CAPITOLO 2. NETATALK 59 nbplkup Utility simile all'utility nslookup nelle reti Tcp/Ip. Viene utilizzato 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 AppleTalk. item[netatalk Webmin Modules] Webmin Sul sito uciale di Netatalk è disponibile (seppure in versione beta), un plugin per la congurazione del server utilizzabile tramite Webmin il noto programma per la gestione Web dei sistemi Linux. In gura... è presente la schermata principale del plugin Webmin il quale consente di settare numerose opzioni della suite Netatalk. E' possibile infatti scegliere quali condivisioni attivare, limitare l'accesso a determinati utenti o gruppi di utenti. Tramite l'interfaccia web è anche possibile modicare le opzioni del le netatalk.conf, che altrimenti andrebbe editato manualmente.

61 Capitolo 3 Cups 3.1 Introduzione La stampa con i sistemi Unix è sempre stata eettuata storicamente con uno dei due seguenti sistemi: Berkley Line Printer Daemon (LPD [31]) o AT&T Line Printer System. Questi sistemi vennero sviluppati agli inizi degli anni settanta, 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 ultimi dieci anni ci sono stati due progetti che hanno cercato di creare una nuova interfaccia di stampa standard: POSIX Printing Standard sviluppato dall'ieee (Institute of Electrical and Electronical Engineers IEEE ) è ormai abbandonato. Questo progetto denisce una serie di tool da linea di comando, unitamente ad un interfaccia C, che servono per l'amministrazione della stampante e dei processi di stampa. Internet Printing Protocol (IPP) sviluppato da Internet Engineering Task Force attraverso il PWG (Printer Working Group). IPP fornisce una serie di estensioni[32] al protocollo HTTP 1.1, allo scopo di fornire supporto per la stampa da postazioni remote. CUPS è stato accettato dall'ietf ed è in attesa di essere riconosciuto come standard, è infatti largamente supportato da molti sistemi operativi Introduzione a IPP Nel 1996, Novell si mise in contatto con alcune aziende che avevano dimostrato initeresse nella ricerca e sviluppo di un protocollo standard per la stampa 1 Con il termine line printer viene indicato un tipo di stampante che stampa una linea per volta, generalmente sono utilizzate in ambienti di lavoro dove è necessario stampare le formato testuale. 60

62 CAPITOLO 3. CUPS 61 su Internet. Un primo documento dal nome LDPA (Lightweith Document Printing Application) fu redatto in seguito alla collaborazione tra Xerox e Novell. Contemporaneamente IBM stava sviluppando un progetto simile per la stampa su Internet, basato sul Web e denominato HTPP (Hypertext Printing Protocol). Sucessivamente alla stesura di questi documenti base per lo sviluppo dei protocolli, venne creato un gruppo di lavoro, chiamato PWG, al quale parteciparono anche produttori di stampanti e produttori di print-server. Grazie al lavoro del PWG le linee guida espresse nei documenti IBM e Novell Xerox vennero implementate all'interno di un protocollo chiamato IPP. Lo scopo principale di questo protocollo è creare uno standard unico per la stampa tramite Internet, minimizzando gli sforzi dei produttori di hardware, tutt'ora costretti a creare per i loro prodotti driver e software necessari per il supporto dei vari protocolli esistenti. Gli obiettivi (raggiunti) dall'ultima versione dell'ipp sono quelli di creare un protocollo a livello applicativo 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 informazioni sullo stato delle stampanti; gestire le transazioni commerciali per la stampa dei documenti noticare automaticamente malfunzionamenti, guasti errori; gestire l'accounting delle stampe. Prima dell'avvento di IPP, lo standard de facto per quello che riguarda la stampa via rete poteva essere considerato LPD [31], limitatamente all'utilizzo con sistemi operativi *nix. Per compatibilità con i sistemi passati, IPP contiente alcune funzionalità per la coesistenza con LPD. Contrariamente a quanto si potrebbe pensare IPP non è un protocollo applicativo implementato nel livello superiore dello schema TCP/IP, ma è incorporato all'interno di particolari richieste HTTP (utilizzando i metodi POST e GET). Il protocollo utilizzato è l'http 1.1, la cui principale differenza rispetto all'http 1.0 è quella di non utilizzare una connessione TCP separata per ciascun oggetto richiesto, con un notevole incrememento delle performance. Per consentire l'incapsulamento di richieste IPP in pacchetti HTTP è stato creato un apposito formato MIME (Multipurpose Internet Mail Extensions) denominato application/ipp. Questo formato MIME è utilizzato come contenitore per le richieste e riposte IPP. Grazie sempre all'utilizzo di questo formato MIME, è possibile trasportare pacchetti IPP anche attraverso SMTP. Un'altro motivo per cui IPP è trasportato in richieste HTTP è facilmente intuibile se si pensa che molti produttori di stampanti implementano già il protocollo HTTP all'interno del loro hardware (semplici web server per

63 CAPITOLO 3. CUPS 62 gestire congurazione e stato dei prodotti). Oltre a questa motivazione se ne può dedurre anche un'altra legata alla diusione del protocollo HTTP, senza contare che introdurre un nuovo protocollo applicativo avrebbe aumentato notevolmente i tempi necessari per la diusione di IPP. In seguito all'ampia standardizzazione di IPP, esso è stato implementato sotto una molteplicità di piattaforme, tramite l'ausilio di software dierenti. IPP è implementano nelle nuove versioni di Windows Server 2003 tramite l'utilizzo di IIS [38], il popolare Internet Server di Microsoft. Anche altre versioni dei sistemi operativi Microsoft (Windows 2000 e Windows Xp) implementano il protocollo IPP, limitandosi però a fornire l'interfaccia client di tale protocollo, orendo la possibilità di stampare su stampanti posizionate su server remoti tramite IPP, ma non consentendo di condividere le stampanti ad essi collegati tramite il protocollo stesso. IPP è invece implementato in ambienti *nix (Unix, Linux, *Bsd, MacOS, ecc) tramite il pacchetto software CUPS. 3.2 Concetti generali La stampa è sicuramente da considerarsi una delle operazioni più complicate nel mondo IT. In principio, ogni sviluppatore di programmi che volesse essere in grado di stampare, doveva prevedere i driver proprietari per la periferica di stampa e ciò era ovviamente molto scomodo e molto complicato. Le cose sono migliorate con l'avveto di una serie di linguaggi e tecniche speciche per la stampa PostScript Un primo sviluppo verso un linguaggio di stampa generico fu fornito da Adobe con l'invenzione di PostScript. Da un lato i programmatori potevano così concentrarsi nella creazione di programmi che dessero in uscita un output PostScript compatibile dall'altro i produttori di hardware dovevano invece creare Hardware compatibile con il linguaggio PostScript. Con il passare 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 (Gracal Device Interface) sviluppato da Microsoft. Il linguaggio PostScript resta comunque il più diuso in ambito *nix. Un esempio di le PostScript è visualizzato in gura 3.1, dove i comandi illustrati servono per guidare la stampante nella creazione delle opportune linee da tracciare. Si tenga presente che, anche se si usa il linguaggio PostScrpt, le stampanti necessitano di un formato Raster da elaborare. Questo formato può cambiare da stampante a stampante richiedendo piccoli aggiustamenti. Le immagini

64 CAPITOLO 3. CUPS 63 %!PS % First 2 characters need to be '%!' (magic numbers). % two boxes % '%' introduces comments. The virtual PS-pen is asked 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 moveto % is constructed in an analogous way., 0 60 rlineto % but this time not just with horizontal rlineto % and vertical lines, but also with lopsided ones 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. Ovviamente tipi di stampanti dierenti necessitano di formati raster in ingresso dierenti per produrre il medesimo output, si pensi alle stampanti ink-jet le quali possono avere da 3 a 6 ugelli di stampa RIP I processi RIP (Raster Imaging Process) servono per convertire i le PostScript in appositi formati raster compatibili con l'hardware a cui sono dedicati. Se si utilizzano stampanti PostScript compatibili, il processo RIP è eettuato dall'hardware stesso, tramite un chip o tramite un calcolatore dedicato. Nel caso in cui non si utilizzino però stampanti PostScript compatibili il processo RIP è eettuato mediante software che accetta in ingresso il formato PostScript e fornisce in uscita un formato raster compatibile con l'hardware dedicato. Non esistono ovviamente dirver PostScript che funzionino bene con tutte le stampanti, ma alcuni di essi forniscono risultati eccellenti, migliori di quelli ottenibili con i driver Windows, si pensi ai driver Gimp-Print. Dalla versione CUPS non utilizza più un driver Ghostscript al suo interno ma fa adamento su una versione esterna chiamata ESP Ghostscript. 2 Un immagine raster è composta da un insieme di pixel ognuno dei quali ha una posizione all'interno di una matrice e una serie di opzioni ad esso associato (colori, luminosità, ecc.)[34]

65 CAPITOLO 3. CUPS Spooler e Demoni di Stampa Oltre a queste faticose operazioni di RIP, ogni strumento software necessita di un meccanismo di SPOOLing, che ore la capacità di gestire e memorizzare job dierenti, utenti dierenti, ltri dierenti e convogliare tutto ordinatamente verso le periferiche di stampa. Lo spooler è gestito da una serie di demoni di stampa. I demoni di stampa sono i processi software tramite cui gli utenti sono invece capaci di calcellare, fermare, riavviare i processi di stampa File PPD I le PostScript sono le di testo semplice, e quindi incapaci di gestire le varie opzioni della stampante. Per sfruttare le potenzialità native di una stampante si ricorre all'utilizzo dei le PPD, le di testo che contengono tutte le opzioni disponibili. I le PPD creati da Adobe sono di fatto diventati uno standard aperto grazie anche all'ottima documentazione fornita. Generalmente i driver della stampante caricano i le PPD (di cui è visible un esempio in gura 3.2) come un le di congurazione aggiutiva, inserendo in un'opportuna interfaccia graca tutte le opzioni della stampante disponibili (duplex, risoluzione, ecc...). Prima dell'avvento di CUPS i le PPD erano utilizzati soltanto in ambienti Windows, ma ora possono essere utilizzati anche in ambiente *nix. I le PPD possono essere utilizzati anche con stampanti che non sono PostScript compatibili. Con l'avvento di CUPS infatti è possibile utilizzare tutte le opzioni disponibili su stampanti non PostScript, mediante l'uso di le PPD. Questi non sono generalmente svilupati dai produttori hardware, i quali si limitano a produrre driver prorietari spesso compatibili solo con Windows, ma sono sviluppati dal team CUPS e da altri programmatori volontari. Gli archivi più importanti di le PPD per stampanti 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ò essere esteso per supportare nuove stampanti, periferiche e protocolli. CUPS è un prodotto free software sviluppato dalla Easy Software Products [33] e rilasciato sotto licenza GNU/GPL e GNU/LGPL (General Public License & Library General Public License). La prima release di CUPS (basata sul protocollo IPP 1.0) venne rilasciata nel settembre 1999, fu seguita da numerose

66 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 lang_encoding char * carattere usato per le opzioni lang_version char * linguaggio usato per le opzioni language_level 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

67 CAPITOLO 3. CUPS 66 Figura 3.3: CUPS struttura generale patch per migliorarne la sicurezza, portabilità e diminuire i big scoperti, ma non vennero aggiunte nuove funzionalità. L'ultima versione di CUPS (ver 1.1) è basata sul protocollo IPP 1.1 aggiunge numerose funzionalità richieste dagli utenti nali. Come molti sistemi di stampa CUPS è strutturato attorno ad uno scheduler che si occupa di smistare i processi di stampa, fornire informazioni sullo stato della stampante ai programmi locali, remoti e agli utenti. In g 3.3 è mostrata la struttura fondamentale di CUPS. Nelle seguenti sezioni verranno spiegati nel dettaglio i singoli componenti del sistema CUPS. 3.4 Scheduler Lo scheduler di CUPS è un server HTTP/1.1, che oltre a gestire le richieste HTTP per il supporto del protocollo IPP, funziona da web server per quello che riguarda la documentazione, il monitoring e l'amministrazione. Lo scheduler gestisce anche una lista delle stampanti disponibili su di una LAN, associando i processi di stampa al relativo Backend o Filtro necessario. 3.5 Conguration File I le di congurazione sono le testuali per le impostazioni del server HTTP, la congurazione delle stampanti e classi di stampanti, ecc Congurazione del server HTTP Il le cupsd.conf simile ai le di congurazione di Apache [35], denisce tutti ì controlli per l'accesso alle risorse del server, ed è utilizzato per la con- gurazione principale dello scheduler. Un esempio di cupsd.conf è visibile in gura 3.4, i principali parametri di congurazione del le sono i seguenti:

68 CAPITOLO 3. CUPS 67 ServerName indica il nome del server CUPS (di default è l'hostname del computer su cui CUPS è installato); DocumentRoot è il percorso per la documentazione locale di CUPS visualizzabile tramite interfaccia web; PreserveJobHistory consente di conservare una lista dei job eettuati; PreserveJobFiles permettee di conservare una copia dei job eettuati; Printcap specica la posizione del le printcap utilizzato per compatibilità con il sistema di stampa BSD; Printcap Format specica il formato del le printcap; ServerBin specica la posizione delle directory dove sono posizionati ltri e backend di cups; ServerRoot specica 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 di rete; BrowseInterval indica la frequenza di aggiornamento delle stampanti in rete tramite browsing. I restanti parametri di congurazione servono per un controllo di accesso a livello utente, alle stampanti condivise o alle classi disponibili. Il server web congurato tramite il le sopracitato, fornisce una comoda interfaccia 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 modicare le opzioni di quelle già installate. Nella sezione dedicata ai Job (g3.8), è invece possibile visualizzare i lavori di stampa eettuati e quelli ancora presenti nella coda di spooling File di congurazione per stampanti Il le di congurazione per le stampanti è printers.conf. Una porzione di questo le è visibile in gura 3.9. Normalmente questo le non è editato manualmente ma è creato tramite lpadmin o l'interfaccia web di CUPS. Il le clesses.conf, che viene anch'esso modicato da lpadmin o da interfaccia web, serve per congurare le classi di stampanti installate sul sistema. Viene denita classe di stampanti un'insieme di stampanti, una stampa inviata ad una classe di stampante viene inoltrata ad una stampante disponibile secondo l'algoritmo Round Robin.

69 CAPITOLO 3. CUPS 68 ServerName nomeserver DocumentRoot /usr/share/doc/cups 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 AuthType None Allow from All </Location> <Location /> Order Deny,Allow Deny From All Allow From All </Location> Figura 3.4: Esempio di cupsd.conf

70 CAPITOLO 3. CUPS 69 Figura 3.5: CUPS: homepage interfaccia web Figura 3.6: CUPS: sezione stampanti interfaccia web

71 CAPITOLO 3. CUPS 70 Figura 3.7: CUPS: sezione classi di stampanti Figura 3.8: CUPS: sezione job di stampa

72 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 Tipologie MIME supportate Le tipologie MIME supportate da sistema CUPS, sono incluse nel le mime.types a cui normalmente non vanno apportate modiche. Utilizzando questo le CUPS controlla le tipologie mime inviate ai client e ricevute da essi. Spedire una tipologia mime corretta ai client è utile anche essi possano associare il le handler più opportuno. 3.6 CUPS API Le CUPS API contengono funzioni utilizzabili nei programmi utente, per accodare processi di stampa, rilevare le informazioni, accedere alle risorse via HTTP e IPP. Le librerie CUPS forniscono inoltre un insieme di interfacce scritte in C che permettono di operare con applicazioni, ltri di stampa, backend e driver per stampanti di CUPS. Di seguito vengono illustrate alcune delle principali API di CUPS, utilizzate dagli sviluppatori del progetto per gestire semplici processi di stampa. In gura 3.10 viene illustrata la funzione cupsprintfile, utilizzata per stampare singoli le. I parametri della funzione sono i seguenti: name è il nome della stamapante o della classe di stampanti a cui inviare il job 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 del job oppure 0 nel caso di errore. In gura 3.11 viene illustrata la funzione cupscanceljob utilizzata per cancellare i processi di stampa accodati.

73 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 di ritorno di una precedente cupsprintfile; status è un intero indicante lo stato della cancellazione, il suo valore è 1 se l'eliminazione avvenuta 0 se l'eliminazione non ha vuto successo. #include <cups/cups.h> 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 monitoring delle code di stampa. Tra queste si ricorda cupsgetsdest, rappresentata in gura Questa interfaccia viene utilizzata per ottenere una lista delle stampanti o classi attualmente disponibili, num_dest indica il numero di risorse disponibili e dest è un puntatore ad una struttura. Le risorse disponibili (classi o stampanti) sono identicate da una struttura visibile in gura #include <cups/cups.h> 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 di errore associato può essere ricavato tramite la funzione cupslasterror(), la quale ha come valore di ritorno il codice di errore IPP associato. Spesso

74 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 di cupserrorstring() che serve per convertire il codice di errore IPP in una stringa testuale più chiara all'utente, si guardi la gura #include <cups/cups.h> 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 che sono congurate con CUPS. CUPS fornisce però una serie di funzioni speci- che per le stampanti Postscript. Queste funzioni servono principalmente per l'accesso e la manipolazione dei le PPD (Postscript Printer Description), che descrivono i caratteri, la dimensione della carta, la risoluzione e altre caratteristiche proprie della stampante in uso. I driver di stampa utilizzano i le PPD per apprendere le capacità e le caratteristiche delle stampanti. In gura 3.15 vengono illustrate le principali funzioni che le CUPS API consento di eetturare su le PPD. filename è il nome del le PPD associato ad una stampante o ad una classe di stampanti, indicata dalla stringa name. Tramite ppdopenfile() si può aprire il le PPD desiderato; ppdclose() è utilizzato per liberare la memoria 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 elencati in gura 3.2.

75 CAPITOLO 3. CUPS 74 #include <cups/cups.h> 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 funzionano da linea di comando forniti da CUPS che orono una completa interfaccia per eseguire print job e vericare lo stato delle stampanti. Tutte le impostazioni che possono essere eseguite tramite la comoda interfaccia Web possono essere eettuate mediante l'utilizzo dei comandi shell che CUPS mette a disposizione. Grazie a questa serie di comandi il server di stampa CUPS consente una completa e sicura gestione remote. Di default il web server CUPS integreato nello scheduler infatti non utilizza connessioni criptate, si incorre così nella possiblità di sning dei parametri di accesso al server. Per comprendere al meglio il funzionamento delle utility da linea di comando fornite con CUPS è necessario capire la struttura delle code di stampa sotto *nix. Ogni coda è identicata da un nome di massimo 127 caratteri, che può contentere numeri e lettere. Le code di stampa hanno anche una periferica associata ad esse (porta parallela, usb, ecc). A ciascuna periferica in CUPS è associato un URI (Uniform Resource Identier) simile alle URL utilizzate dai browser. Alla prima porta parallela è associato ad esempio l'identicativo: parallel:/dev/lp1. Sucessivamente verranno elencati alcune delle più comuni utility utilizzate con CUPS lpstat lpstat deriva dall'omonimo comando di gestione stampe fornito da System V. lpstat visualizza informazioni sulle classi correnti, job di stampa e stampanti. Se viene invocato senza argomenti, lpstat lista tutti i lavori in coda dall'utente.

76 CAPITOLO 3. CUPS lp status Questo comando, ereditato dall'omonimo di System V, viene utilizzato per stampare le su una stampante specicata (opzione -d destination). Le opzioni 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 lpc status lpc status è una piccola utility che fornisce un controllo limitato sulle code si stampa presenti in CUPS. Può essere utilizzato per capire lo stato di una coda di stampa. lpc adotta una sintassi simile a quella del comando omonimo implementato dal sistema di stampa Berkely. A causa di una compatibilità col passato, molte utility congurabili per le code installate sotto CUPS non sono disponibili con lpc status, è consigliato l'utilizzo di lpadmin come suo sostituto lpq lpq è derivata dall'omonima utility di Berkeley, dalla quale eredita la sintassi, viene utilizzata per interrogare le code di stampa (se non è specicata nessuna coda viene utilizzata quella predenita) lprm e cancel Utility derivate dalle rispettive omonime di Berkely e System V per la rimozione dei job di stampa da una coda lpadmin lpadmin è il comando principale di CUPS, utilizzato per gestire le stampanti e le classi di stampanti. La sintassi generale del comando lpadmin è visibile in gura 3.16 Le opzioni utilizzate sono le seguenti lpadmin [ -E ] lpadmin [ -E ] lpadmin [ -E ] -d destination -p printer option(s) -x destination Figura 3.16: lpadmin: sintassi generale -E serve per specicare se i dati inviarti al server vanno critpati o meno.

77 CAPITOLO 3. CUPS 76 -d imposta la stampante o classe specicata come default per il sistema -x elimina la stampante o classe specicata cupsaddsmb Questa utility fornisce un ottimo support per l'integrazione tra CUPS e il server Samba. Infatti grazie a questo tool è possibile esportare le stampanti CUPS installate sul sitema in modo che siano visibili sul network SMB. La sintassi del comando è visibile in gura 3.17 cupsaddsmb [ -H samba-server ] [ -U samba-user ] [ -h cups-server ] [ -v ] -a Le opzioni utilizzate sono: Figura 3.17: cupsaddsmb: sintassi -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'esportazione; -a esporta tutte le stampanti; -h specica un server CUPS da utilizzare lpinfo lpinfo mostra tutte le periferiche disponibili o i driver riconosciuti dal sistema 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 e le riversano, modicato, sullo standard output. Anche CUPS si avvale di ltri per la stampa. Tutti i ltri devono supportare un set comune di opzioni incluso il nome della stampante, job ID, username, job title, numero di copie e opzioni eventuali. Il sistema di ltering di CUPS è essisbile e molto

78 CAPITOLO 3. CUPS 77 potente, ed è creato con una struttura di tipo modulare. Grazie a questa sua caratteristica tutti i ltri di terze parti sono utilizzabili con semplicità, e vi è anche la possibilità di creare ltri personalizzati come ad esempio quelli forniti 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 uscita il formato raster specicio per l'hardware a cui sono destinati. Uno dei ltri più importanti da utilizzare con CUPS è foomatic foomatic foomatic naque nel 2000, quando CUPS non era ancora molto conosciuto e supportava solo un centinaio di stampanti, CUPS comprendeva già il ltro pstoraster (da PostScript a raster) e aveva un ottimo supporto per le stampanti Postscript grzie all'uso dei le PPD. L'autore di foomatic aveva un database molto vasto con l'elenco di stampanti a cui associare un opportuno le PostSript. La sua idea fu quella di generare le PPD dal suo database di informazioni, e usare questi le per creare ltri standard per il funzionamento con CUPS. Grazie a questa idea si riusci ad aumentare notevolmente il numero di stampanti funzionanti con CUPS, fornendo tutte le opzioni avanzte di CUPS (interfaccia web, classi di stampanti) a tutte le persone che volevano utilizzare i driver Ghostscript pap Un altro ltro che può essere utilizzato è pap. Questo compnente della suite Netatalk ore la possibilità di installare e gestire tramite CUPS le stampanti congurate dal server papd Netatalk. Così facendo si rendono disponibili alla rete *nix le stampanti AppleTalk di dicile utilizzo. 3.9 CUPS Imaging Queste librerie CUPS forniscono un supporto per il trattamento delle immagini, come ad esempio impostazione dei livelli di colore, scalatura delle immagini per la stampa, ecc. La libreira più famosa per il trattamento delle immagini è sicuramente costituita dai ltri gimp-print[39]. Gimp-print Gimp-Print è un insieme di driver per la stampa ad alta qualità utilizzabile sotto diverse piattaforme: Linux, BSD, Solaris, IRIX, e altri *nix piattaforme. In molti casi questi driver hanno più funzioni dei driver standard forniti con le periferiche. L'obiettivo del team di sviluppo di Gimp-Print è ottenere la più alta qualità di stampa disponibilie dalle stampanti. Le

79 CAPITOLO 3. CUPS 78 libreire Gimp-Print non orono solo supporto per la stampa attraverso il noto programma di graca, orono inoltre plugin utilizzabili con foomatic e ltri di stampa dalle caratteristiche avanzate per CUPS. Normalmente i ltri Gimp-Print per CUPS non sono inclusi in una intallazione standard del programma (ad eccezzione dell'installazione di CUPS in Mac OSX). Le caratteristiche 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 semplicata dei driver; supporto per un ampia scala di regolazioni (luminosità, contrasto, sintonia colori); utility per permettere il supporto completo di molte stampanti Epsone e Lexmark (indicazione di livello di inchiostro, carta esaurita, ecc); ampia documentazione per sviluppatori e utilizzatori Backends Backends è un ltro speciale che invia dati direttamente ad una periferica o ad una connessione. CUPS prevede backends per interfacce parallele, seriali, USB, LPD, IPP, JetDirect. Samba (dalla versione in poi), prevede un ottimo backend per poter stampare sulle stampanti *nix da sistemi Windows. La congurazione di Samba, per poter condividere sulla rete SMB le stampanti installate sotto CUPS, prevede normalmente l'inserimento delle seguenti opzioni in smb.conf visibili in gura printing=cups printcap=cups Figura 3.18: smb.conf: uso delle stampanti CUPS Samba Backend In questa sezione verrà analizzato l'utilizzo di Samba come backend per CUPS per consentire ai client Windows di stampare su stampanti CUPS. Per eettuare questa condivisioe di risorse, visualizzabile in gura 3.19, si hanno due possibilità, l'utilizzo dei driver del produttore forniti con la stampante, l'utilizzo dei driver Ghostscript forniti con CUPS.

80 CAPITOLO 3. CUPS 79 RAW Printing Figura 3.19: stampa di rete tra client server eterogenei Installando tramite CUPS la stampante come RAW printer, i client Windows vanno impostati per utilizzare i driver uciali forniti dal produttore hardware, così facendo si possono sfruttare tutte le potenzialità della stampante (es: stampa fronte retro, stampa più di una pagina per foglio, ecc...) fornite dai driver uciali. Grazie all'uso combinato di CUPS e Samba, si può impostare il le server di modo che i client che tentano di connettersi ad una stampante ricevano in automatico i driver dal server. Questa funzionalità è molto comoda e diminuisce il tempo di installazione delle stampanti sui client. Nella share [print$] del le smb.conf di gura 3.20 vanno inseriti i driver opportuni per la stampante. In seguito a queste impostazioni il sistema GDI dei client produrra in output un formato Windows EMF (Enhanced Meta File, immagini raster) speciche per l'hardware a cui sono destinati. Con questa congurazione, il server CUPS viene utilizzato come semplice server di SPOOLing, ovvero i client forniscono a CUPS dati con un formato già comprensibile per la stampante. CUPS si occupa solo dell'inoltro dei dati verso la stampante. Questa congurazione, non necessita di un 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 server CUPS come software RIP, impostando sui client il driver ADOBE PostScript, eventualmente associandolo al download automatico tramite Samba come