A mia nonna Frassidera

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "A mia nonna Frassidera"

Transcript

1 A mia nonna Frassidera

2 Indice 1 GRID Cos e? L architettura GRID Interoperabilità Descrizione dell Architettura Situazione Attuale della GRID L architettura di glite Alien, Globus Toolkit, Kerberos e Xen Virtualizzazione Para-Virtualization Xen A Kerberized Certification Authority Kerberos SSL/TLS Kerberos Credential Translator per il WEB Globus Toolkit OGSA-WS-WSRF GT AliEn L Architettura di Alien Installazione Installazione di Xen Installazione di Kerberos e AFS Installazione AFS Installazione di KCA & Kx Installazione di un sistema batch: SGE Installazione di Globus Configurazione della Security Configurazione del GridFTP, RFT e GRAM Configurazione di WebMDS Globus Delegation e KCA Criptografia a Chiave Pubblica e X Criptografia a Chiave Publica Certificati X

3 ii INDICE 4.2 GT4 Delegation Delegation e single sign-on simple-ca e KCA simple-ca Submit di un job su Globus KCA e Globus Confronto tra KCA e simple-ca globusrun-ws da itterbio a disprosio Futuri sviluppi AliEn a Firenze Installazione Configurazione Installazione di un Worker Node Installazione di AliRooT AliEn in Esecuzione Possibile Sviluppo: AliEn e KCA Conclusioni 91 A Messaggi in debug di globusrun-ws 93 A.1 globusrun-ws con autenticazione verso simpleca A.2 globusrun-ws con autenticazione verso KCA A.3 Messaggi in debug di globusrun-ws di un job sottomesso da una simpleca riconosciuta ma esterna al pool di Globus

4 Elenco delle figure 1.1 GRID Architettura GRID Layered I Servizi di glite Architettura del WMS di glite Visione globale dell architettura di glite Virtualizzaziione Shared OS Virtualization Confronto Para-Virtualization & Full System Virtualization Para-virtualizzazione Xen Logo Kerberos Autenticazione Kerberos Protocollo di handshake SSL Protocollo KX Protocollo KCT Collaborazione OGSA-WSRF Architettura dei Web Services WSDL Stubs Interazione Client/Server di un Web Service Server Side di un applicazione Web Service Implementazione della struttura di GRAM Diagramma degli stati di un job in Globus Componenti di ALiEn Architettura di ALiEn File Catalogue di ALiEn Autenticazione di ALiEn Pull Model di ALiEn MonALISA Sistema di Monitoring di ALiEn Sala Macchine Dipartimento di Matematica U. Dini terbio.math.unifi.it, olmio.math.unifi.it e itterbio.math.unifi.it erbio.math.unifi.it e tulio.math.unifi.it Web MDS Main page Web MDS Group Detail Web MDS RFT Detail Ctittografia a Chiave Pubblica Generazione di una Firma Digitale

5 iv ELENCO DELLE FIGURE 4.3 Esempio di un certificato Digitale CA trustworthy Delegation Un esempio di certificato rilasciato dal proxy Un esempio di certificato rilasciato dal proxy Login ed Informazioni di un accesso al Globus Toolkit Selezione di KCA come CA di default AliEn Installer AliEn Installer - Errore piattaforma non impostata Selezione pacchetti per l installazione di AliEn a Firenze LDAP VO AliEn - Florence - Configurazione CE LDAP VO AliEn - Florence - Configurazione SGE LDAP VO AliEn - Florence - Configurazione Monitor La coda di SGE Site di Firenze Inserito nella VO di ALICE ma inattivo Site di Firenze Inserito nella VO di ALICE attivo ma senza jobs in coda Site di Firenze Inserito nella VO di ALICE attivo e con jobs in elaborazione Tre jobs Attivi su Firenze Active jobs in Florence Zombie jobs in Florence

6 Ringraziamenti Vorrei ringraziare i miei genitori per il sostegno con cui hanno accompagnato la mia carriera universitaria e non solo, mia sorella, mio cognato, che forse è più un fratello, le nonne e gli zii. Un grazie particolare va al mio Relatore, Prof. Gregorio Landi, che mi ha permesso di fare una stupenda esperienza presso il CERN, al mio correlatore Dott. Alberto Mancini che mi ha sostenuto moralmente e professionalmente durante tutta la fase di sviluppo di questa tesi. Un Grazie a Massimiliano Masi, Ceri Stefano e Giacomo Sacchetti, che hanno condiviso con me gioie e dolori degli esami universitari. Non posso escludere dai miei ringraziamenti la mitica V C che dagli anni del liceo non mi ha mai abbandonato, i R.I.C. (Ettore compreso) che ormai sono parte della mia famiglia, i mitici compagni della Pallamano Calenzano e gli amici Alessio, Federico, Adriano, Sara, Eleonora, Elisa, Matteo, Riccio, Sato, Alessandro, Konse, Luca, Ilaria, Bizio, Zaza, Claudia, Chiara, Gianni, Monia, Maso e Francesca. Pensando che sono solo circa ventitre anni che la conosco come posso esimermi dal ringraziarla. Grazie Francesca per aver condiviso con me asilo, elementari, medie, superiori e non solo. Un grazie anche a tutte le persone che mi hanno sopportato in questi ultimi mesi durante la stesura di questa tesi, ovvero tutti i colleghi della Savino del Bene IT, la Fefi, il mio neurone Ciccio Sara e la mitica Laura (o multa che corre). Un grazie particolare è rivolto ad una persona speciale che mi è vicina nonostante tutto, che mi sopporta nei momenti permalosi e mi rallegra quando lo sconforto (ok le menate che mi faccio da solo) prendono il sopravvento: GRAZIE ELENA.

7 vi ELENCO DELLE FIGURE

8 Introduzione Lo scopo di questo lavoro è analizzare un ambiente GRID nelle sue componenti, con particolare attenzione al sistema di autenticazione e delega delle credenziali proponendo un alternativa all utilizzo di certificati X.509, basata sul sistema di autenticazione Kerberos. Struttura dei capitoli Diamo uno sguardo all organizzazione dei capitoli. Nel Capitolo 1 introdurremo il concetto di GRID System. Vedremo cosa sono i sistemi Grid, come è iniziata la ricerca in questo settore e quali sono le problematiche che intende affrontare. La Grid research è in rapida evoluzione e progetti ed iniziative di vario tipo nascono frequentemente in ogni parte del mondo. Cercheremo di dare le informazioni di base sui progetti di maggior interesse e visibilità. Nel Capitolo 2 descriveremo i software che compongono l ambiente di test utilizzato per verificare l effettivo funzionamento dell approccio presente in questa tesi. Vedremo in dettaglio i concetti di Virtualizzazione, Certification Authority come servizio Kerberos, Globus Toolkit e AliEn. AliEn è uno degli ambienti GRID sviluppati presso il centro europeo di ricerca nucleare (CERN ). Nel Capitolo 3 descriveremo la realizzazione dell ambiente di lavoro di questa tesi. Vedremo in dettaglio i passaggi necessari per l installazione di Xen, come sistema di virtualizzazione, Kerberos e AFS, come sistema di autenticazione e storage distribuito, KCA e Kx509, come Certification Authority basata su Kerberos (Kerberized CA), Sun Grid Engine, come sistema batch, Globus Toolkit 4, come ambiente di studio e testing per i sistemi di autenticazione Grid e AliEn. Nel Capitolo 4 descriveremo il sistema di autenticazione attualmente usato dagli ambienti GRID e il sistema proposto come alternativa. Vedremo in dettaglio il funzionamento dell autenticazione con le Certification Authority adottate dai Sistemi GRID come glite e AliEn e mostreremo come sia possibile usare come Certification un sistema di autenticazione basato su Kerberos. Nel Capitolo 5 descriveremo la realizzazione di un ambiente GRID reale, AliEn. Vedremo come si installa e lavora un sito del gruppo di ricerca ALICE (A Large Ion Collider Experiment), presso il CERN di Ginevra. Inoltre delineeremo come

9 2 ELENCO DELLE FIGURE applicare i test svolti nel capitolo precedente a questa realtà, permettendo ad utenti di un site krb (dotato di un sistema di autenticazione Kerberos) di accreditarsi verso la GRID, mediante l utilizzo dei servizi della KCA. Inoltre mostreremo i vantaggi che si otterrebbero nel gestire la GRID con macchine virtuali, ovvero avere la possibilià di mantenere gli host vivi anche durante le sostituzioni (o manutenzioni) hardware, in quanto XEN permette la migrazione di una macchina in esecuzione risultando totalmente trasparente all utente ed alle applicazioni. È disponibile una versione di questa tesi in lingua inglese al seguente url:

10 1GRID As computer networks become cheaper and more powerful, a new computing paradigm is poised to transform the practice of science and engineering.[10] Ian Foster 1.1 Cos e? The GRID (La Griglia) è il nome con cui viene chiamato il progetto che dal 1999, si propone di fornire una visione globale delle risorse computazionali (CPU e Storage) di coloro che decidono di partecipare a questo progetto [11]. Figura 1.1: GRID Quando si parla della Grid, ci viene presentato un nuovo modo di pensare ed usare il computer. L idea base è la volontà di creare un enorme Super Computer ([7])

11 4 CAPITOLO 1. GRID unendo le risorse di ogni piccola unità che compone la griglia ottenendo un immensa potenza di calcolo, impensabile altrimenti. L insieme delle tecnologie usate viene definito Grid Computing e le componenti Virtual Organizatons (VO). Il concetto di Organizzazione Virtuale è stato formulato per evidenziare la natura che unisce i componenti di una griglia, siano questi persone fisiche o VO sottostanti (Università, gruppi di ricerca, ecc..). Ogni membro mette a disposizione le prorpie risorse (hardware e software) defininendo chiaramente cosa è condiviso, a chi è permesso condividere e le condizioni sotto cui è disponibile la condivisione. Secondo queste direttive si è cercato di costruire l infrastruttura per ottenere un modo flessibile, sicuro e coordinato per condividere risorse tra gruppi dinamici di persone, dando così origine alla tecnologia della griglia, di cui elenchiamo i principali servizi: Autenticazione Sicurezza Autorizzazione Naming Scheduling Servizio per l esecuzone remota Il principale compito di questi servizi è quello di generare un unica interfaccia indipendentemente dalla configurazione di ogni Virtual Organization. 1.2 L architettura GRID Questa tecnologia è stata pensata per rendere possibile una condivisione flessibile di risorse tra le VO partecipanti. Un esempio pratico e chiaro si ha pensando alla ricerca scientifica, ad esempio al Cern, dove tanti gruppi di ricerca partecipano all esperimento LHC e devono condividere risorse. Grazie alla tecnologia GRID (che non a caso è stata sviluppata principalmente al Cern:AliEn e GLite, di cui parleremo nel capitolo successivo, sono nati e sono tuttora sviluppati presso il centro di ricerca europeo) viene condivisa questa conoscienza permettendo a tutti i membri di poter effettuare i propri studi jobs, rendendo possibile il lavoro dei vari gruppi su moli di dati altrimenti intrattabili. Il problema principale è quindi permettere alle Vitual Organization di stabilre relazioni di condivisione per raggiungere un efficace INTEROPERABILITÀ. Questo concetto espresso su una rete di computer equivale a definire dei protocolli comuni in grado di garantire i servizi richiesti (Sez. 1.1), spesso definito middleware Interoperabilità Le relazioni definite per ottenere un efficace condivisione dovono: Facilitare l ingresso dinamico di nuovi utenti, indipendentemente dalla piattaforma, dal linguaggio e dall envirovment di programmazione (flessibili e leggeri).

12 1.2. L ARCHITETTURA GRID 5 In assenza di protocolli capaci di garantire questo tipo di collaborazione, le VO sarebbero costrette ad effettuare condivisioni bilaterali, difficilmente erogabili a terze parti. Un particolare ancor più vincolante sarebbe la creazione di nuove VO che necessiterebbe di specifiche veramente limitanti. Risulta quindi evidente la necessità di standard protocols and syntaxes, rivoluzionando così le modalità di condivisione, proprio come il WEB (HTTP e HTML) ha rivoluzionato lo scambio di informazioni. La vera difficoltà nel creare questo standard risiede nel concedere la massima, se non totale, libertà ai meccanismi locali di sharing, poichè le istituzioni (VO) posso cambiare nel tempo cambiando così le politiche locali di gestione delle risorse. Per preservare questa peculiarità i protocolli gestiscono le interazioni tra le componenti e non le loro implementazioni. Per coaudiuvare meglio l interoperabilità tra le componenti della GRID sono stati utilizzati i Web Services, che sono definiti dal protocollo che usano e dal comportamento per cui sono stati implementati. Definendo uno standard services per ogni servizio offerto alle VO si può astrarre la modalità adottata localmente per fornirlo. Un maggiore interoperabilità è stata raggiunta grazie alla definizione di APIs (Application Programming Interfaces) e SDKs (Software Development Kits), che permettono agli sviluppatori delle VOs di elaborare software sofisticati per ambienti di esecuzione dinamici e complessi senza rinunciare alla possibilità di condividerli con la GRID Descrizione dell Architettura Il risultato delle considerazioni precedenti è stata la realizzazione di un architettura a layer seguendo i principi del hourglass model (modello a clessidra) ([14]). Figura 1.2: Architettura GRID Layered Il collo della clessidra è rappresentato da un insieme di astrazioni (soprattutto riguardanti le risorse) e dai protocolli (TCP e HTTP, ovvero la connectivity).

13 6 CAPITOLO 1. GRID La parte alta della clessidra invece rappresenta le molteplici astrazioni sui differenti comportamenti che possono essere definiti su questi protocolli che a loro volta sono definiti sulle diverse tecnologie possibili, parte bassa della clessidra. Passiamo ora ad analizzare brevemente i livelli di questa architettura: FABRIC CONNECTIVITY RESOURCE COLLECTIVE APPLICATIONS Fabric Questo livello fornisce l accesso alle risorse che vengo condivise dal protocollo della Griglia, per esempio un sistema di storage, un catalogo o una risorsa computazionale. I Fabric Component implementano quindi le specifiche locali necessarie per l accesso alle risorse (fisiche o logiche), che ad alto livello sono viste come il risultato di una normale operazione di condivisione. Ovviamente le specifiche implementate a questo livello vincolano fortmente le operazioni permesse ai layer superiori. Si è scelto di richiedere ai Fabric Component solo delle funzionalità minime sulle quali si basa l astrazione dalla risorsa sottostante, ovvero: 1. un enquiry mechanism per poter ottenere informazioni sullo stato le capacità della risorsa. 2. un resource managment per erogare effettivamente i servizi messi a disposizione della Griglia. Connectivity In questo layer vengono definiti i protocolli di comunicazione e autenticazione richiesti per una transazione GRID specifica. Quelli definiti per la comunicazione favoriscono lo scambio di dati tra più Fabric Layer. I protocolli relativi all Autenticazione garantiscono meccanismi di crittografamento sicuri per il riconoscimento di utenti e risorse. Le principali soluzioni adottate dalle VO per il processo di autenticazione hanno le seguenti caratteristiche: + Single sign on: Gli utenti devono avere la possibilità di accedere a tutte le risorse grid per cui possiedono i permessi effettuando il login una sola volta. + Delegation: Un utente deve avere la possibilità di delegare le proprie credenziali di accesso alle risorse ad un programma da lui eseguito.

14 1.2. L ARCHITETTURA GRID 7 + Integration (Integrazione con i sistemi alle VO locali di sicurezza): Le soluzioni adottate localmente devono poter essere non vincolate dalla Grid e la Grid Security deve essere in grado di interagire con esse. + User-based trust solution: Un utente deve poter usufruire contemporaneamente delle risorse a cui può accedere senza un interazione tra i security administrator dei siti a cui appartengono le risorse. Resource Questo livello fornisce un set di protocolli (e APIs e SDKs) elaborati sopra al Connectivity layer. Servono a garantire una sicura negoziazione, il monitoraggio, il controllo e tutte le operazioni necessarie per la condivisione delle singole risorse. L implementazione di questi rotocolli viene denominata Fabric layer (accesso e controllo locale delle risorse). Questo livello cura solamente gli aspetti relativi alle singole risorse lasciando il compito di una visione globale della Griglia al Collective Layer. I protocolli sviluppati da questo livello possono essere suddivisi in due classi principali: + Informazione: Rende possibile conoscere la struttura e lo stato di una risorsa + Controllo: Fornisce il meccanismo di negoziazione dell accesso alla risorsa, controllando che le condizioni di condivisione della risorsa siano rispettate dalla richiesta. Collective Rispetto al livello precedente questo focalizza l attenzine sull insieme delle risorse partecipanti alla GRID e soprattutto alle loro interazioni. In questo layer è infatti possibile implementare varie tipologie di condivisione senza dover imporre nuovi requisiti alle risorse sottostanti. Esempi di funzionalità messe a disposizione delle VO dal Collective Layer sono: + Directory services: Permette di rilevare l esistenza e le proprietà delle risorse partecipanti. + Co-allocation, scheduling, and brokering services: Permette alle VO di allocare una o più risorse.

15 8 CAPITOLO 1. GRID + Monitoring and Diagnostics services: Monitoriza lo stato delle risorse evidenziando eventuali intrusioni. Le Collective functions possono quindi essere implementate come servizi persistenti, poichè sono associati a protocolli specifici, SDKs e APIs a cui le applicazioni fanno riferimento. Applications L ultimo livello della GRID fornisce le applicazioni per l utente che si interfacciano direttamente con gli ambienti delle VO. Queste sono ovviamente costruite su i servizi forniti dai livelli sottostanti e possono essere di qualsiasi tipologia, non facendo mai riferimento alla struttura delle risorse utilizzate. Le applicazioni rappresentano infatti la parte superiore della clessidra. CLI Access API Security Authorization Auditing Authentication Information & Monitoring Information & Monitoring Application Monitoring Data Management Workload Management Metadata Catalog File & Replica Catalog Accounting Job Provenance Package Manager Storage Element Data Movement Site Proxy Computing Element Workload Management Figura 1.3: I Servizi di glite 1.3 Situazione Attuale della GRID Attualmente il progetto Grid è sostenuto da tutta la comunità scientifica mondiale, guidata dall unione Europea che ha riunito tutti i progetti correlati sotto EGEE (Enabling Grids for E-Science in Europe). Lo scopo di questo progetto è stato dare credibilità e stabilità al progetto GRID, che si era sviluppato in numerosi gruppi di ricerca senza una vera coordinazione e condivisione di conoscenza. Il primo passo di EGEE è stato quello di re-ingegnerizzre e integrare le varie attività di ricerca e creare così un middleware di componenti robuste. I due maggiori progetti che ne tracciano le linee guida sono e sono stati AliEn e LCG (LHC Computing Grid),

16 1.3. SITUAZIONE ATTUALE DELLA GRID 9 entrambi sviluppati presso il CERN come supporto all esperimento LHC. Il lavoro di EGEE ha cercato di riunire le specifiche dell architettura GRID sotto un unico progetto che, basandosi sulle esperienze dei gruppi di ricerca come ALICE (uno dei quattro esperimenti presenti in LHC, CERN) ha dato vita all EGEE Grid Middleware, chiamato glite L architettura di glite glite segue l architettura Service Oriented così da garantire l interoperabilità dei servizi GRID e facilitare il supporto degli standard OGSA (Open Grid Service Architecture), basati sugli stessi principi. L implementazione è quindi basata sulla tecnologia dei Web Services, le cui interfacce sono definite usando il linguaggio WSDL ([6]). Le componenti di glite, come detto sopra, derivano dai progetti già esistenti tra i quali il più influente è LCG, come risulta evidente dalla figura 1.3, che descrive i servizi di glite, ma potrebbe essere usata per descrivere quelli di LCG. I pricipali servizi offerti dal middleware possono essere raggruppati in: Security Service API and Grid Access Service Inormation and Monitoring Services Job Management Service Data Services Security Service È composto dai servizi di autenticazione, autorizzazione e verifica, che provvedono al riconoscimento delle entità (utenti, sistemi e servizi), alla concessione dell accesso alle risorse e la memorizzazione delle informazioni utili per l analisi di sicurezza relative agli eventi (ovvero viene salvata ogni informazione relativa alle azioni eseguite dall utente nel sistema). API and Grid Access Service Forniscono un framework comune per l accesso ai servizi della GRID. L Accesso serve a gestire il ciclo di vita di un servizio generico della GRID, in conseguenza ai diritti concessi all utente che lo sta usando. Ovviamente nonostante nella figura 1.3 siano rappresentati come servizio, le API non lo sono ma servono a tarcciare la modalità per accedervi. Inormation and Monitoring Services È il meccanismo che si propone di recuperare e pubblicare le informazioni relative allo stato delle risorse della Griglia. Per fare un esempio più specifico si può pensare al Job Monitoring Service, che è in grado di rappresentare in tempo reale lo stato di un job e lo stato che raggiunge dopo aver terminato tutte le sue transazioni.

17 10 CAPITOLO 1. GRID Job Management Service Questo servizio (gestione ed esecuzione dei jobs) è delegato ai Computing Element (CE), che relazionano tra di loro attraverso il workload management system (WMS). Esistono due politiche di gestione del WMS: Figura 1.4: Architettura del WMS di glite 1. Push Model: Il WMS decide su quale CE mandare i job in base alle caratteristiche richieste dal job e allo stato delle risorse disponibili su ogni Computing Element. 2. Pull Model: Il CE fa la richiesta al WMS del job specfico e lo preleva direttamente dalla coda. Data Services La gestione e l acesso ai dati è suddivisa tra tre gruppi: Storage Element (SE), Catalog Services e Data Management. La suddivisione delle competenze tra questi gruppi è stata pensata per la gestione dei file, ma è abbastanza generica per essere applicata ad un qualsiasi altro livello dello storage. In un ambiente distribuito si ha la necessità di usare e gestire le repliche, ovvero molteplici istanze dello stesso file su postazioni fisiche differenti così da ottimizzare le prestazioni. Per Gli utenti della GRID un file e tutte le sue copie sono identificate da un logical file name (LFN), memorizzato e raggiungibile grazie al Catalogo delle Repliche (RC). Tutto questo è visto da un utente come un file system globale, dove le repliche ono

18 1.3. SITUAZIONE ATTUALE DELLA GRID 11 voms-proxy-init UI JDL Input sandbox Output sandbox Resource Broker Input sandbox + Broker Info data info SE & CE info Output sandbox Data Catalogs Information Service Author. &Authen. Job Submit Event Logging & Book-keeping Job Query Job Status JDL Globus RSL Job Status Job Submission Service Job Status Publish Storage Element Computing Element Figura 1.5: Visione globale dell architettura di glite completamente trasparenti, infatti queste sono raggiungibili slo se tracciate dal RC e vengono identificate attraverso un Site URLs. All intero della griglia l accesso ai file è permesso solo attraverso gli Storage Element e controllato con le ACL (Access Control Lists) in tipico stile Unix. La semantica di accesso ai file è completamente dipendente dal sistema sottostante e per questo prevede molteplici modalità. Il Data Management è un altro problema non banale della gestione dati. Infatti ogni singolo dato può essere considerato come un job. Pe questo motivo per decidere a chi concedere l accesso ad un determinato dato si ricorre ad un Data Scheduler (DS) e ad un meccanismo che si occupa dei trasferimenti dei file FTL (Fie Transfer Library). Tutto questa strutura permette di ottenere le repliche aggiornate e quindi uno stato consistente di tutto lo storage presente nella GRID.

19 12 CAPITOLO 1. GRID

20 2 Alien, Globus Toolkit, Kerberos e Xen 2.1 Virtualizzazione In quest ultimo anno si è assistito ad un incremento esponenziale dell interesse nei confronti della virtualizzazione, tanto che gli stessi produttori di chip stanno costruendo i loro nuovi prodotti cercando un sempre più completo supporto per la virtualizzazione dell hardware. La Virtualizzazione è la tecnica con la quale risorse hardware come processore, storage, I/O e rete possono essere condivise da più macchine, dette virtuali. Un layer hardware/software permette di simulare o emulare tali risorse abilitando l esecuzione di molteplici ambienti, ognuno dei quali risulta di fatto un sistema completo. Si può dire che la virtualizzazione permette di dividere una macchina fisica in tante piccole macchine con configurazioni, ambienti e sistemi operativi totalmente differenti, creando l illusione di essere in presenza molte macchine. Esistono quattro approcci per virtualizzare un sistema Figura 2.1: Virtualizzaziione che differiscono per il livello a cui si effettua la virtualizzazione:

21 14 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Full System Virtualization: è la tecnica che prevede una totale virtualizzazione a livello hardware, ovvero avere la possibilità di eseguire parte delle istruzioni per l emulazione direttamente sull hardware e parte sul VMM (Virtual Monitor Machine). Il più grande vantaggio di questo approccio è che il sistema operativo ospite e le applicazioni che girano su di esso non necessitano di modifiche. Il problema più grande invece è che al momento questo non è relizzabile, poichè l hardware sul mercato non supporta totalmente il tipo di istruzioni richieste, che con buone probabilità l Intel e AMD includeranno nelle versioni future Figura 2.2: Shared OS Virtualization Para-Virtualization: questa richiede che il sistema operativo sia modificato in modo da trasformare quelle istruzioni che non possono essere virtualizzate completamente. Infatti per ovviare a questo sia il sistema ospitante che quello ospitato devono essere ricompilati in modo da rendere possibile la para-virtualizzazione. Le applicazioni da eseguire in entrambi i sistemi invece non richiedono modifiche. Hosted Virtual Machines: adotta un metodo in cui il VMM e il sistema ospite lavorano direttamente nelle user space della macchina host. Quindi i programmmi dell host e del guest condividono lo stesso user space e le stesse risorse, che sono fornite alla VMM direttamente dalla macchina host. Il vantaggio maggiore è che non è richiesta nessuna modifica al sistema ospite e alle applicazioni da eseguire. Di contro invece questo approccio è caratterizzato da una elevata mole di lavoro a carico dell host, che pregiudica fortemente le performance del sistema. Shared OS Virtualization: prevede la partizione di una macchina in tanti contenitori isolati dove i processi, la memoria e tutti i device condividono solo l immagine del kernel. Ogni contenitore viene chiamato Virtual Private Server.

22 2.1. VIRTUALIZZAZIONE Para-Virtualization La Para Virtualizzazione è la tecnica, come accennato sopra, dove il set di istruzioni hardware che non supportano la virtualizzazione sono modificate. Figura 2.3: Confronto Para-Virtualization & Full System Virtualization Modificare un set di istruzioni significa che le modifiche, relative all istruzioni che fanno riferimento all hardware non virtualizzato nativamente, devono essere portate anche verso il sistema operativo (ovvero il kernel) poichè dovrà far riferimento al nuovo insieme di istruzioni. Nella maggior parte dei casi le applicazioni non richiedono modifiche poichè non fanno uso di istruzioni che modificano i registri interni dell hardware o relative allo stato della macchina. Creando questo set parallelo set di istruzioni, deve essere implementato un hypervisor, che possa ospitare i kernels delle macchine guest. Seguendo questo approccio tutte le modifiche necessarie per la virtualizzazione sono fatte al momento della compilazione e non richiedono nessuna traduzione a run-time, non incidendo così sulle performance che risultano nella maggior parte dei casi simili a quelle di Full System Virtualization. Fare un confronto fra queste due tecniche risulta facile poichè differiscono solo per alcuni driver. L hypervisor, infatti mette a disposizione del sistema ospite solo quelle istruzioni che nativamente non supporterebbero la virtualizzazione, quindi gli scambi di messaggi tra VMM e macchina guest sono ridotti al minimo indispensabile in quanto gli altri driver sono di fatto un canale diretto tra hardware e sistema ospite come avviene in una virtualizzazione nativa. Il più grande svantaggio di questa tecnica risiede nella necessità di modificare il kernel del sistema, cosa che spesso non è possibile per problemi di licenza, come nel caso di Microsoft Windows Xen Xen è un monitor di macchine virtuali Open Source, l hypervisor, rilasciato sotto licenza GPL per piattaforma x86 e compatibili, sviluppato dall Università di Cambridge. La tecnica usata per l emulazione è la para-virtualizzazione. Xen consente una completa emulazione hardware senza andare a ridurre in modo drastico

23 16 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN le risorse del sistema, emulando sistemi operativi diversi tra loro. l accesso verso l hardware passa attraverso l hypervisor, che si occupa anche di fornire l user space necessario per i sistemi ospiti. Gli ospiti necessitano solo di saper interagire con il layer dell hypervisor incaricato di emulare l hardware. Virtualizzazione Linux Day 2005 Architettura di Xen Sempre in continuo sviluppo e sperimentazione, Xen ha tra i suoi finanziatori Xen in pratica nomi del calibro di AMD e Microsoft. Passiamo ora ad analizzare brevemente A colpo d occhio l architettura di Xen. Figura 2.4: Para-virtualizzazione Xen Guido Trotter Virtualizzazione di macchine Linux tramite XEN Architettura Xen: CPU, Memoria e Input Output Attualmente, sia Intel che AMD, hanno sviluppato indipendentemente le estensioni di virtualizzazione dell architettura x86 denominate Intel VT ( Virtualization Technology) e Pacifica (AMD Virtualization). Per assistere la virtualizzazione, VT e Pacifica hanno introdotto un nuovo livello privilegiato al di sotto del ring 0 1. Entrambe le soluzioni hanno aggiunto 9 nuove istruzioni che lavorano solamente nel livello denominato Ring -1, create appositamente per essere usate dall hypervisor. Questo permette di eseguire sistemi guest senza modificarne il sistema operativo e riducendone il costo di emulazione. Ovviamente quest ultimo non è eleminato del tutto in quanto ogni sistema operativo deve essere convinto che da solo ha accesso alla memoria della macchina ed ai bus di I/O, mentre in realtà è sempre l hypervisor che manipola l accesso ai dispositivi reali. La memoria è stata parzialmente virtualizzata a partire dai 386, nel senso che il SO e un controller hardware di memoria, assegnavano la RAM fra le applicazioni. AMD presenta un vantaggio in questo ambito perchè le sue CPU includono il controller di memoria che Pacifica può semplicemente riutilizzare. In contrapposizione, le CPU Intel demandano il controllo di memoria ad un circuito integrato separato che non supporta VT, comportando un maggiore lavoro da parte dell hypervisor nell amministrazione della memoria. Il controller di memoria Intel in futuro sarà introdotto nella CPU e potrà essere in grado di usare VT. Attualmente, la virtualizzazione di I/O richiede dei driver in esecuzione nell hypervisor, che si occupa di presentare i driver virtuali ai sistemi operativi guest. Le 1 da mettere spiegazione

24 2.2. A KERBERIZED CERTIFICATION AUTHORITY 17 future versioni di Pacifica e VT elimineranno i driver dall hypervisor, permettendo ai driver dei sistemi ospite di comunicare direttamente con l hardware. Questo consentirà con ogni probabilità a Xen di passare ad una virtualizzazione completa. Xen in pratica Analizzando Xen dal punto di vista dell utente, possiamo dire che è composto da un Domain-0, che è il primo sistema virtuale ed è anche il sistema dall interno del quale tutte le altre macchine virtuali possono essere gestite. Tale sistema è il primo a fare il boot, inserendosi al livello del kernel direttamente alla partenza del sistema (Xen non è un sistema operativo completo, e non può esistere da solo ). Altri domini possono avere l accesso a parte dell hardware, se specificato nella configurazione. Si possono usare diversi media come backend per i filesystem dei domini: Partizioni fisiche (statiche, veloci) Partizioni su LVM (ridimensionabili, veloci) File su disco (dinamici, allocazione sparsa, lenti, facili da condividere) Una caratteristica molto importante di Xen è la migrazione. Tutti i domini (tranne il Domain-0) possono essere fatti migrare a caldo 2 tra diverse macchine Xen (appartenenti alla stessa regione di broadcast). Per permettere questa feature i filesystem di backend devono essere visibili in partenza da entrambe le macchine. Questa carateristica è estremamente utile per poter fare manutenzione sui server che ospitano le macchine virtuali senza dare disservizio, oppure per bilanciare lõuso delle risorse tra le macchine fisiche o ancora aggiungerne nuove in maniera trasparente. 2.2 A Kerberized Certification Authority Prima di analizzare direttamente l idea e l effetiva ralizzazione di una Certification Authority Kerbeized anilzziamo rapidamente le componenti che devono essere messe insieme per realizzarla: Kerberos e SSL/TLS. Figura 2.5: Logo Kerberos 2 mentre i sistemi sono in esecuzione

25 18 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Kerberos Kerberos è un sistema di autenticazione basato sul protocollo di Needham-Schroeder. L Autenticazione viene raggiunta solo quando una delle due parti può dimostrare all altra di aver scoperto il segreto che hanno in comune. Per rendere l accordo sulle chiavi di complessità qudratica, Kerberos coinvolge, nel processo di autenticazione, una teza parte fidata: il KDC, Key Distribution Center. Ad esempio se Alice è un Kerberos Principal (ovvero un utente di Kerberos), e Bob è un servizio Kerberized entrambe condividono un segreto con KDC. Quando Alice deve effettuare KDC Alice 5 Bob Figura 2.6: Autenticazione Kerberos il login, per usufruire dei servizi di Bob, riceve un TGT (Ticket Garanting Ticket, una chiave di sessione criptata) dal KDC dopo avergli confermato la sua identità comnicadogli la propria password. Con il TGT Alice si può rivolgere ad un TGS (Ticket Garanting Service) e richiedere il Service Ticket per potersi definitivamente autenticare verso Bob, dimostrando al servizio Kerberized che è a conoscenza della chiave di sessione contenuta nel service ticket. ClientHello SSL/TLS ServerHello Certificate CertificateRequest ServerHelloDone SecureCLIENT Socket Layer è un protocollo per la gestione di connessioni sicure, SERVERgaran- tendo l autenticazione ClientKeyExchange delle entità, la confidenzialità e l integrità dei messaggi su Certificate una rete untrusted. CertificateVerify Finished Finished Il protocollo si basa sulla crittografia a chiave pubblica, in particolare fa uso dei certificati per l autenticazione Application Data e una chiave segreta cosí Application da garantire Data confidenzialità e integrità al canale di comunicazione. SSL si compone di due sotto protocolli: SSL record: definisce il formato usato per trasmettere i dati SSL handshake: usa il protocollo SSL record per negoziare un contesto sicuro per la sessione.

26 2.2. A KERBERIZED CERTIFICATION AUTHORITY 19 ClientHello CLIENT Certificate ClientKeyExchange CertificateVerify Finished ServerHello Certificate CertificateRequest ServerHelloDone Finished SERVER Application Data Application Data Figura 2.7: Protocollo di handshake SSL Nella figura 2.7 viene mostrato come interagiscono server e client per negoziare il contesto per la sessione. L autenticazione si basa su una chiave pubblica e un certificato di identita di tipo X509, si nota che SSL supporta la mutua autenticazione. Per prima cosa l utente procede ad autenticare il server, ha infatti la responsabilità di verificare tutte le informazioni, come firma, durata, stato di revoca che sono contenute nel certificato ricevuto dal server. A questo punto l utente invia la propria chiave pubblica al server e per provare che è lui il detentore della chiave privata correlata, invia un messaggio con l hash criptato della firma digitale che entrambe conoscono. Se il server riesce a leggerlo allora la prova è stata supreata e il contesto è stato stabilito. SSL permette anche la rinegozziazzione del contesto dopo un primo handshake, basta infatti che il client ne inizi un altro e la rinegoziazione comincia. Tutto il meccanismo risulta abbastanza pesante dal punto di vista di scambio di messaggi e calcoli crittografici; per semplificare e rendere più veloce la negoziazione di un contesto SSL permette di riusare le sessioni precedentemente usate, ovviamente tutto questo è demandato alla configurazione del server Kerberos Credential Translator per il WEB Lo scopo di questo progetto è implementare un sistema che permetta ad un utente di usufruire di un servizio Kerberized mediante un Web Server con le infrastrutture e politiche di sicurezza esistenti. Lo schema di realizzazione ha seguito le seguenti direttive: Il sistema deve cercare di non modificare i software sottostanti, Web Browser/Server e autenticazione Kerberos, quando possibile Non devono essere aggiunte difficoltà agli amministratori di sistema, poichè comprometterebbero la sicurezza Non devono essere aggiunte difficoltà per l utente, il sistema deve essere facile da usare e non deve richiedere l acquisizione di nuove credenziali Il Web server è vulnerabile quindi deve essere guidato Il sistema deve prevedere un sistema centrale per la gestione delle decisioni sulla poilitca delle azioni del Web Server

27 20 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN e le seguenti assunzioni di sicurezza: Il Web Server ha adeguate misure di sicurezza fisiche Il KDC ha adeguate misure di sicurezza fisiche Tutti gli utenti si fidano di una Certification Authority comune. Ovvero si suppone l esistenza di una Public Key Infrastructure. Il progetto si compone quindi di tre componenti che descrivo di seguito: KCA, KX.509, KCT. KCA & KX.509 Il KX.509 è un meccanismo di autenticazione single-sign-on che permette di ottenere sia le credenziali Kerberos che quelle PK (Public Key). KDC 1 Alice KCA Figura 2.8: Protocollo KX.509 Lo scambio di messaggi e le specifiche del prottocollo sono riportati in figura 2.8. Prima di dare una breve descrizione della dinamica riportata in figura è necessario specificare la natura e i compiti di una KCA. La KCA è un servizio kerberized che dalle informazioni del TGT crea un cetificato X.509, risultando di fatto una CA Kerberized. Rispetto ad una classica CA la KCA non gestisce gli utenti, effettua solo una traduzione correlando credenziali Kerberos con credenziali X.509. Tornando alla figura vediamo come quali siano i passi per ottenere un certificato da un TGT. KX.509: Per prima cosa l utente si autentica su Kerberos (vd ) ottendo un TGT dal KDC. A questo punto per ottenere un certificato del tipo X.509, deve prima chiedere un service ticket e preparare una coppia di chiavi pubblica/privata per poter interagire con la KCA. Quindi procede ad inviare alla KCA il service ticket {User, KCA, K U,KCA } ed un autenticatore{t } KU,KCA. Per essere sicuri di non avere alterazioni nei messaggi, vengono inviati insieme sia la chiave che l HMAC della stessa. Per calcolare l HMAC viene

28 2.2. A KERBERIZED CERTIFICATION AUTHORITY 21 KCT usata la chiave di sessione K U,KCA. La KCA quindi verifica sia il ticket che l autenticatore e genera un certificato X.509 a partire dalle credenziali Kerberos inviandolo all utente che lo aveva richiesto. Per evitare alterazioni, viene aggiunto l HMAC al messaggio di risposta. Le credenziali PK così ottenute hanno una durata pari a quella del TGT Kerberos. Abbiamo visto come la KCA si occupi di tradure le credenziali Kerberos sotto forma di certificato X.509. Analizziamo ora il processo inverso, traduzione da credenziali PK a Kerberos, il KCT. KDC 1 Web Server KCT Figura 2.9: Protocollo KCT Per prima cosa il Web Server che desidera tradurre le credenziali PK deve autenticarsi verso il KDC e presentare un service Ticket verso il KCT accompagnato dal corrispondente autenticatore. Quindi il Web Server fa pervenire l SSL transcript e la chiave di sessione al KCT che dopo averlo autenticato procede con i seguenti passi: Verifica che il transcript SSL sia un handshake valido Valida se i certificati dell utente e del server sono firmati da una KCA fidata Verifica la firma del CLIENT VERIFY, ovvero ricalcola l hash del messaggio di handshake relativo al CLIENT VERIFY e lo confronta con quello dell SSL handshake Web browser kpkcs11 Ticket cache SSL handshake Web server kct_module Verifica che l identita contenuta nel certificato del Server sia tra le identità di Kerberos. Questo ci assicura che il Web Server abbia partecipato kinit kx509 all handshake SSL Token cache Si Assicura che ilkdc transcript KCA sia valido (conrtolla KCT AFStimestemp, lifetime del certificato,ecc...) Genera un service ticket per l utente

29 22 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Cripta la chiave di Sessione e il Service Ticket con la chiave del Web Server Manda al Server il ticket, l autenticatore e la chiave di sessione Scrive traccia di queste operazioni sul file di log Dalle operazioni che deve eseguire un KCT risulta evidente che accedendo al databse del KDC deve godere delle stesse misure (fisiche) di sicurezza. In pratica è altamente consigliabile che i due, KCT e KDC risiedano sulla stessa macchina. 2.3 Globus Toolkit Il Globus Toolkit è un programma nato grazie alla collaborazione tra l Argonne National Laboratory, l Information Sciences Institute dell Università della Californa del Sud, le Università di Chicago e di Edinburgo e lo svedese Center for Parallel Compueters, che rappresenta lo standard de facto, come lo ha definito il New York Times, per l implementazione del Middleware Grid. Implemeta tutti i servizi necessari per un infrastruttura GRID dettati dalle direttive dell OGSA(Open Grid Services Architecture) risultando così la piattaforma pii usata dai progetti scientifici Grid- Oriented. Questo progetto è nato nel 1997 ed è attualmente alla quarta versione. Prima di analizzare la struttura e i servizi rilasciati dal GT4 è essenziale conoscere tre acronimi che costituiscono le basi su cui è stato costruito: OGSA, WS e WSRF OGSA-WS-WSRF OGSA e WSRF sono i concetti chiave su cui nasce e si sviluppa Globus. OGSA è il progetto, del Global Grid Forum (http://www.ggf.org), che cerca di definire una linea guida per lo sviluppo di applicazioni GRID. Questo in pratica consiste Figura 2.10: Collaborazione OGSA-WSRF nella trovare uno standard accettato dalla comunità mondiale che definisca le interfacce dei servizi tipici di questa architettura (job management services, resource

30 2.3. GLOBUS TOOLKIT 23 management services, security services, ecc.). Il primo importante passo affrontato da OGSA risiede nella scelta di un middleware distribuito su cui sviluppare tutta l infrastruttura, ovvero creare un ambiente per i servizi che permetta di specificare metodi universali per invocarli. Le opzioni prese in considerazione sono state molteplici, CORBA, RMI, o le tradizionali RPC ma alla fine i Web Services sono risultati quelli più idonei e affini alle specifiche dettate da OGSA, nonostante una loro grave mancaza: la caratteristica di essere stateless. Per rendere i WS completamente compatibili è stato inserito il WSRF (Web Services Resource Framework, svilupato da OASIS 3 ), che si occupa di rendere possibilie il binomio Web Services-Grid. Specifica come sia possibile realizzare WS stateful (fig. 2.10), infatti possiamo dire che se OGSA è l architettura, WSRF è l infrastruttura su cui viene realizzata. Web Services I Web Services sono, come detto sopra, un altro middleware per sviluppare applicazioni in ambienti distribuiti di tipo Client/Server. Come suggerisce il nome è una tecnologia Web che a differenza dei siti web non ha nessuna relazione con i Browser e l HTML, infatti si può dire che i siti web interagiscono con le persone, mentre i Web Services solamente con i software, esattamente come CORBA e gli altri middleware distribuiti. I WS rispetto alle altre tecnologie affini presentano dei vantaggi notevoli: Sono indipendenti dalla piattaforma e dal linguaggio (sfruttano le peculiarità del linguaggio XML). Ad esempio il client può essere scritto in C++ ed essere eseguito su un terminale Ms Windows, mentre il server sviluppato in Java è in esecuzione su un sitema Linux. Il canale di comunicazione dei WS è l HTTP; questo deve essere considerato un vantaggio perchè è uno dei pochi se non l unico canale che di default non è soggetto a particolari attenzioni da parte dei firewall. e ovviamente alcuni svantaggi: Overhead. Trasettere tutti i dati via XML non è efficiente come sfruttare i prorietary binary, infatti quello che si guadagna in portabilità viene perso in efficenza, infatti non troveremo mai applicazioni Critical Real-Time sviluppate con i Web Services. Di contro è vero che di solito il carico di lavoro che un ambiente Grid sviluppa risulta accettabile, e l aspetto della portabilità prevale. Mancanza di versatilità. Infatti tendono a fornire solamente i servizi base di cui un architettura ha bisogno, mentre ambienti come Corba mettono a disposizione dell utente numerose tipologie di servizi: persistency, notification, life cycle management, transaction, ecc. Comunque grazie a specifiche come il WSRF i Web Services stanno acquisendo una sempre più completa versatilità. 3

31 24 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Considerando vantaggi e svantaggi e che a differenza di Corba e le altre tecnologie i WS sono loosely coupled systems, ovvero non richiedono sistemi simili per buone prestazioni, risultano essere i candidati migliori per l architettura OGSA. Architettura dei Web Services Prima di esaminare come si richiedono i servizi verso un WS è sicuramente opportuno delineare l architettura dei Web Services. Come si vede dalla figura 2.11 Figura 2.11: Architettura dei Web Services l architetura dei WS è costituita da quattro livelli: - Service Processes Non è relativo ad un solo WS, infatti é il livello coinvolto nel discovery service, che vedremo successivamente quando descriveremo il funzionamento di un Web Service. - Service Description Una delle capacità più interessanti dei WS è il self-describing. Quindi una volta scoperto dove si trova il servizio, grazie al livello precedente, è possibile chiedergli informazioni sulle operazioni supportate e su come richiamarlo. Questo avviene con lo scambio di messagi scritti in WSDL (Web Services Description Language), linguaggio specifico per la descrizione di un WS. - Service Invocation Richiamare un Web Service richiede lo scambio di alcuni messaggi tra Client e Server secondo un protocollo ben preciso, SOAP (Simple Object Access Protocol), che regola sia il formato delle richieste che quello delle risposte. Ovviamente SOAP non è l unica soluzione, un alternativa potrebbe essere XML-RPC, ma è sicuramente la più usata. - Transport Infine abbiamo la gestione della trasmissione dei messaggi SOAP tra Client e Server. Ci sarebbero vari protocolli per gestire la trasmissione ma il più usato è l HTTP (HyperText Transfer Protocol), lo stesso usato per accedere alle pagine Web. Tipica chiamata di Web Services Per decrivere le fasi di interazione di un applicazione Client/Server basata sui Web Services è necessario introdurre due concetti fondamentali Client Stub e Server Stub.

32 2.3. GLOBUS TOOLKIT 25 Figura 2.12: WSDL Stubs Gli stubs sono porzioni di software delegate dal Client/Server per la creazione e la trasmissione dei messaggi. Esistono numerosi tools che generano automaticamente gli stubs necessari per la creazione e traduzione dei messaggi SOAP. Questa operazione segue le direttive del WSDL descriptor, che permette ai WS di astrarre dal linguaggio del server in quanto adotta uno standard accettato da tutti per la definizione dei parametri caratterizzanti della chiamata. Facendo riferimento alla figura 2.13 vediamo in dettaglio cosa succede quando viene invocato un Web Service: 1. Quando il client vuole richiamare i servizi di un WS, in realtà invia la propria richiesta verso il Client Stub. Questo risponde inserendo il messaggio in un adeguata richiesta SOAP. Questa operazione viene spesso definita processo di marshaling or serializing. 2. La richiesta SOAP viene inviata tramite il protocolo HTTP ed Internet. Il Server riceve il messaggio SOAP e passandolo al Server Stub riesce a tradurre il messaggio in qualcosa che il servizio è in grado di interpretare, comunemente chiamata operazione di unmarshaling or deserializing. 3. Il Server Stub quindi procede ad inoltrare la richiesta verso l implementazione del servizio che la processa secondo le direttive ricevute. Figura 2.13: Interazione Client/Server di un Web Service 4. Il risultato ottenuto passa quindi dal Server Stub che lo include in una SOAP response. 5. Questo messaggio viene quindi inviato tramite il protocolo HTTP ed Internet verso il client. Il Client Stub qundi traduce il messaggio SOAP in modo da renderlo leggibile. 6. Infine il client accede al risultato ricevuto in seguito alla sua richiesta e ne fa l uso per cui lo a richiesto.

33 26 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Quelli appena descritti sono i passi che rappresentano il fulcro di una richiesta SOAP per invocare un Web Service, dopo che il servizio richiesto è stato localizzato. Server Side di un Web Service Rimane un ultimo aspetto interessante da analizzare relativa ai Web Services: la struttura del Server. Figura 2.14: Server Side di un applicazione Web Service Osservando la figura 2.14 risulta chiaro che il server è composto da quattro livelli: Web Service: Come prima cosa ci sono i Web services, porzioni di software che offrono la possibilità di effettuare determinate operazioni. Ad esempio un implementazione in C++ di alcuni metodi (operazioni). Come abbiamo detto in precedenza il WS non necessità di conoscere come leggere o scrivere messaggi SOAP. SOAP Engine : Si occupa di gestire messaggi (richieste e risposte) SOAP. Spesso non si ricorre ai Server Stub per ogni singolo WS ma si usa un generico SOAP engine, come Apache Axis, come nel Globus Toolkit. Questo livello si occupa solamente di manipolare SOAP, infatti la parte che effettivamente esplica le funzionalità di server è demandata agli altri livelli. Application server: Questo livello si occupa di fornire un living space per le applicazioni che devono essere raggiunte da client diversi. Solitamente il SOAP engine è un applicazione di un application server. Nel nostro esempio Axis è il SOAP engine e il suo application server è Jakarta Tomcat. HTTP Server: Spesso l Application Server esercita anche le funzionalità di server HTTP, altrimenti viene inserito un altro software che si occupa di gestire i messaggi HTTP, come ad esempio un Apache Server, comunemente definito Web Server GT4 Il Globus Toolkit vesione 4 è un insieme di componenti software pensate per creare un sistema distribuito, dove ambienti diversi interagiscono scambiandosi messaggi

34 XX GLOBUS Ninf-G: Remote Procedure Call on the Grid 2.3. TOOLKIT 27 XX. in una rete. Per essere più precisi dobbiamo specificare che il GT4 è un insieme di 4.7 Services Case Studies Web che creano la base di un sistema distribuito veramente eterogeneo. How dare many?un What? attached Per ideahere di or quale sia to laearlier vera sections? natura del GT4, descriverò le componenti essenziali su cui si sviluppano tutti i servizi di Globus: GRAM ( Grid Resource Execution Management Case Study 1 Allocation and Management), MDS ( Meta Directory Service), GSI ( Grid Security XX Infrastructure) Execution Management Case Study 2 XX GRAM Il Grid Resource Allocation and Management è il servizio che rende possibile la 4.8 How GRAM Worksdi job allocando una risorsa computazionale remota. sottomissione e il controllo We review the GRAM information should be interest as l accesso Grazie allebriefly peculiarità deiimplementation. Web services,this GRAM è in grado di of permettere background to the discussion of GRAM configuration ( 4.5) and also to users wantreliability. some alle risorse di un sistema distribuito eterogeneo garantendo una who buona insight into how GRAM works and to developers as an example of a WSRF/WSN-based service. Job tions func Delegate GT4 Java Container GRAM GRAM services services Delegation Transfer request RFT File Transfer Compute element Local job control De l e gate sudo Client Service host(s) and compute element(s) GRAM adapter GridFTP FTP control Local scheduler User job FTP data GridFTP Remote storage element(s) Figure 10: GRAM implementation structure Figura 2.15: Implementazione della struttura di GRAM As illustrated in Figure 10, the primary elements of a GRAM deployment are as follows:! A set of services running in a GT4 Java container, as follows: La procedura che un utente deve seguire per sottomettre un job consiste in due o GRAM-specific services for creating, monitoring, and managing jobs soli passaggi: o A general-purpose delegation service, used to manage delegated credentials editare un file xml, come nell esempio 2.1, dove descrivere il job e le sue dipendenze (sistema operativo, librerie, ecc...) eseguire il comando globusrun-ws < f ilexml > Draft of 5/8/2005 A questo punto GRAM prende in gestione il lavoro e seguendo le specifiche descritte nel file esamina le code dei sistemi batch degli host a disposizione del sistema e seleziona quello più idoneo all esecuzione. Procede quindi ad allocare la risorsa prescelta lasciando così la gestione relativa all esecuzione al sistema locale, rilasciando all utente l handle, che gli permetterà di seguire il processo nel sistema. Nel GT4 a conferma di una sempre maggior compatibilità verso tutti i sistemi sono supportati come cluster management system: Condor, PBS, LSF e SGE (Sun Grid Engine, uno degli ultimi sistemi batch messi a disposizione da Sun). Comment [ ITF30] : Wha authorization callouts?

35 28 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Listato 2.1: Esempio di uno script GRAM relativo ad un job 1 <? xml version =" 1.0 " encoding ="UTF -8"?> 2 < multijob 3 xmlns:gram =" http: // www. globus. org / namespaces /2004/10/ gram / job " 4 xmlns:wsa =" http: // schemas. xmlsoap. org /ws /2004/03/ addressing "> 5 < factoryendpoint > 6 < wsa:address > 7 https: // resource - manager -0. globus. org:8443 / 8 wsrf / services / ManagedJobFactoryService 9 </ wsa:address > 10 < wsa:referenceproperties > 11 < gram: ResourceID > Multi </ gram: ResourceID > </ wsa:referenceproperties > 14 < wsa:referenceparameters /> 15 </ factoryendpoint > <job > 18 < factoryendpoint > 19 < wsa:address > 20 https: // resource - manager -1. globus. org:8443 / 21 wsrf / services / ManagedJobFactoryService 22 </ wsa: Address > 23 < wsa:referenceproperties > 24 < gram: ResourceID > Fork </ gram: ResourceID > 25 </ wsa:referenceproperties > 26 < wsa:referenceparameters /> 27 </ factoryendpoint > < executable >/ bin / echo </ executable > 30 < argument >Hello,</ argument > 31 < argument >Grid </ argument > 32 < argument >From </ argument > 33 < argument >Subjob </ argument > 34 < argument >1</ argument > 35 <count >1</ count > 36 </ job > <job > 39 < factoryendpoint > 40 < wsa:address > 41 https: // resource - manager -2. globus. org:8443 / wsrf / services / 42 ManagedJobFactoryService 43 </ wsa: Address > 44 < wsa:referenceproperties > 45 < gram: ResourceID > Fork </ gram: ResourceID > </ wsa:referenceproperties > 48 < wsa:referenceparameters /> 49 </ factoryendpoint > < executable >mpi - hello </ executable > 52 < argument >Hello,</ argument > 53 < argument >Grid </ argument > 54 < argument >From </ argument > 55 < argument >Subjob </ argument >

36 State Description Unsubmitted Job has not yet been submitted GLOBUS TOOLKIT StageIn Job is waiting for stage in of executable or input files to complete. Pending 29 Comment [ IT meaning of un The local scheduler has not yet scheduled the job for execution. < argument >2 </ argument > 57 < count >2Job </ count > Active is executing. 58 < jobtype > mpi </ jobtype > Suspended Job execution has been suspended. 59 </ job > 60 </ multijob > 56 StageOut Job execution has completed; output files are being staged out. CleanUp DoneMDS Job execution and stage out have completed; clean up tasks are underway. Job has completed successfully. Il Meta Directory Service ha il compito di reperire dinamicamente informazioni Failed Job failed. sulle risorse disponibili e sui loro cambiamenti di stato. Questo permette infatti Comment [ IT job be terminate status? Failed? Killed status? Suspended Unsubmitted Active Pending Done StageOut StageIn Failed CleanUp Figure 8: State transition diagram for GRAM jobs. Figura 2.16: Diagramma degli stati di un job in Globus File Staging and Other Features altri sevizi di has conoscere lo stato dellocated sitemaondistribuito. Le due In allagli examples so far, di theglobus executable been assumed to be the target computer, principali di MDS inputfunzionalità data is passed as arguments, and sono: output data has been written to files on the target computer. However, there will also be cases in which the executable or other files need to be staged in to the targetdiscovery: computer and/or output mustidonea be staged We specify file staging task by adding file trovare la files risorsa per out. eseguire un determinato transfer directives to the job description. These directives follow the RFT syntax, which enables third-party transfers. Each file transfer therefore a source URL and Monitoring: è il processo chemust si occupa dispecify osservare le risorse e/o ai destination servizi per permettere la soluzione di problemi e eseguire il tracking di un task Draft of 5/8/2005 Per garantire queste funzionalità MDS fornisce un aggregator services che raccoglie le informazioni sullo stato attuale delle risorse e fornisce un interfaccia, come un browser o la linea di comando stessa, che permette all utente di visionare le informazioni raccolte. Il Meta Directory Service nella versione 4 a differenza delle precedenti, fa uso dei WS per fornire i servizi e del formato XML per lo storage dei dati, facilitando così la ricerca dei dati con l uso di Xpath, un esempio chiaro è la ricerca di una entry in un albero LDAP. Gli aggregator services che MDS4 mette a disposizione sono tre: 1. MDS-Index: Permette di effettuare richieste Xpath su gli ultimi valori ottenuti dalle fonti di informazioni 2. MDS-Trigger: Si occupa di effettuare alcune azioni, come mandare una mail o scrivere un file di log, quando le informazioni raccolte coincidono con i criteri specificati dall utente Comment [ IT e.g., additional

37 30 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN 3. MDS-Archiver: Salva tutte le informazioni del sistema su di una base di dati permettendo così agli utenti di ricostruire uno storico con delle semplici richieste verso una base di dati. GSI La Grid Security Infrastructure provvede a gestire e garntire le condizioni di sicurezza nella comunicazione interna di una rete Grid. Implementa i servizi necessari per gestire le caratteristiche del livello connectivity descritto nella sezione del secondo capitolo. I componenti relativi alla sicurezza si occupano quindi di stabilire l identità di un utente o un servizio, Autenticazione, e proteggere le comunicazioni e determinare chi è abilitato a fare cosa, Autorizzazione. Entrambe le funzionalià sono implementate sulla base dei certificati X.509 ed il protocollo di comunicazione SSL (Secure Sockets Layer 4 ). Parlando specificatamente di GSI relativa al Globus Toolkit 4 si deve specificare che i WS security sono sviluppati su tre meccanismi: 1. Message Level: dove sono implementati gli standard WS-Security e WS-SecureConversation che garantiscono la protezione del messaggio durante lo scambio delle richiste SOAP di GT4 2. Transport Level: delega tutte le sue funzioni al TLS (Transport-Layer-Security) 3. Authorization Framework: permette di usare vari schemi di autorizzazione, come il grid-mapfile per il controllo degli accessi, con il solo vincolo che rispettino lo standard X.509 e che si scambino le informazioni relative alle autorizazioni secondo il protocollo SAML. Infine altri due importanti compiti di GSI sono la Delegation e la propagazione delle credenziali X.509. La propagazione è svolta da MyProxy che provvede a distribuire le credenziali, dell entita autenticata, verso tutti i servizi a cui ha diritto. La Delegation invece prevede un meccanismo di mapping che permette di demandare a sistemi alternativi l autenticazione sempre con l importante vincolo dello standard X Secure Sockets Layer è un protocollo di comunicazione che garantisce gli standard di sicurezza richiesti in Grid basato sulla crittografia a chiave asimmetrica vd. sezione 2.2.2

38 2.4. ALIEN AliEn AliEn (Alice Environment) è un ambiente di calcolo distribuito sviluppato da Alice Offline Project per offrire a tutti i membri dell esperimento un accesso trasparente alle risorse, sia di calcolo che di storage, indipendentemente dalla loro locazione fisica. Quest ambiente è stato sviluppato per affiancare le fasi di sviluppo di uno degli esperimenti di LHC, ALICE. Infatti AliEn affianca i membri dell esperimento mettendo a disposizione degli utenti una piattaforma di lavoro capace di sostenere gli sviluppi futuri del calcolo distribuito, seguendo il paradigma del GRID Computing. Figura 2.17: Componenti di ALiEn Alien è frutto dell unione di un gran numero di programmi OpenSource di cui sono state sfruttate le peculiarità senza modificarne il codice. Questo ha permesso un rapido sviluppo delle nuove versioni del software. Attualmente è usato da Alice per il calcolo distribuito dei dati, per il rilievo e la ricostruzione delle simulazioni del metodo di Monte-Carlo. La struttura di AliEn è composta di un insieme di circa trenta siti distribuiti sui quattro continenti. Un punto di forza di questo progetto del Cern è l estrema semplicità del sistema di installazione (un installer reperibile su ) che con un semplice script (alien-installer)permette di installare le componenti richieste e le loro dipendeze senza alcun intervento da parte dell utente. Al termine dell installazione si ottiene la configurazione di una nuova Virtual Organization, composta dai Web Services che collaborano e costituiscono l Alien Grid. Le prerogative su cui è nato e cresciuto Alien rispetto al sitema sottostante sono state: risultare più indipendente possibile essere flessibile avere una semplice procedura di installazione su sistemi di calcolo di grandi dimnsioni

39 32 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Queste tre caratteristiche assieme al fatto che sia completamente compatibile con la GRID del Cern (LCG) secondo i parametri dettati dal consorzio Europeo EGEE, hanno fatto si che AliEn abbia avuto un ottima diffusione nella comunità scientifica L Architettura di Alien La struttura (fig.2.18) è sostanzialmente suddivisa in tre gruppi: Software esterno Servizi e CORE di Alien Interfacca (Software ad alto livello) Software Esterno Questo livello è coposto da quattro software principali, rigorosamente Open Source: Un RDBMS (MySql) e Core e Moduli Perl: La ragione per cui Alice Offline ha scelto lo scripting language Perl è essenzialmente dovuta alla sua preponderante presenza nel Software libero in tema di algoritmi di crittografia, compatibili con la piattaforma clietn/server di SOAP e facilmente integrabili con il Web. In particolare questo linguaggio offre un modulo di accesso ai Database molto flessibile, perfetto per l implementazione di una Database Interface (DBI) dove il driver del DB è selezionao a run time. Figura 2.18: Architettura di ALiEn LDAP (Lightweight Directory Access Protocol): È un database gerarchico utilizzato per salvare tutte le informazioni relative alle singole Virtual Organizations che compongono l AliEn Grid. Le informazioni contenute nel DB sono principalmente riferite a Persone, Ruoli,

40 2.4. ALIEN 33 Pacchetti, Siti e tutte le informazioni che caratterizzano la VO rispetto alla Griglia. Ad esempio nei file di configurazione di una VO non si specifica che codice venga sviluppato in un detrminato sito poichè questo tipo di informazioni vengono ricavate estraendole dall albero LDAP dinamicamente. VO Pakages & Command: Ogni singola VO è tenuta a fornire informazioni riguardo al software installato e ai comandi che gli utenti della Grid possono eseguire attraverso lo specifico sito. Queste specifiche sono mantenute dall AliEn Pakage Manager, che si occupa inoltre di tenere aggiornate tutte le possibili dipendenze che un comando può avere rispetto a determinati pacchetti. Seguendo questo schema si riesce a mantenere una buona consistenza del softwre prodotto dalle VO che appartengono ad una stessa Griglia. Servizi e Core di AliEn Il Core di Alien è composto da: Database Interface: L elemento principale di AliEn può essere considerato un database relazionale o una federazione di database relaionali, anche eterogenea. In realtà tutto viene memorizzato su MySql. Per permettere ai client di non essere obbligati ad usare un unico driver per la connessione, le richieste verso il Db passano da un Proxy Service. Questo significa che le applicazioni hanno a disposizione un driver particolare AlienProxy, che permette l installazione del driver specifico solo sulla macchina che ospita il servizio di Proxy. File Catalogue: Questa è stata la prima componente realizzata ed il primo successo raggiunto. Si propone di essere la naturale estensione di un file system con l importante carateristica di non trattare mai fisicamente i files. Infatti il file catalogue si occupa solamene di mantenere un associazione tra Logical File Name (LFN) e Physical File Name (PFN) e informazioni utili su i jobs in esecuzione, simulando una /proc analoga alla directory dei sistemi Linux. Metadata Catalogue: Per semplificare l accesso alla gerarchia del File Catalogue, è stata affiancata una nuova tabella che contiene tutte le entità archiviate ( files, directory e sotto directory). A questa vengono associate altre tabelle che riflettono i diritti di accesso e i metadata, cosi da semplifcare sia la ricerca dei files che la negoziazione per accedervi. Configuration Manager: È il responsabile delle interazioni con l LDAP server. Seleziona ed estrae tutte le informazioni che caratterizzano la VO rispetto al contesto e le memorizza in una cache. Questo ottimizza le frequenti consultazioni verso LDAP. Pakage Manager: Come detto precedentemente provvede a tenere aggiornati i pacchetti e i

41 34 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Figura 2.19: File Catalogue di ALiEn comandi che possono essere eseguiti su una VO. Questo implica che, al momento in cui la politica di una VO decide di accettare una tipologia di job, il Pakage Manager si occupa di installarvi tutti i pacchetti per le dipendenze (di librerie) di cui quel nuovo comando ha bisogno. In correlaziione al Core di AliEn i servizi hanno un ruolo centrale nel rendere AliEn un ambiente di calcolo distribuito. I servizi possono essere raggruppati in quattro sezioni principali: Figura 2.20: Autenticazione di ALiEn Autenticazione: Questa si occupa di verificare le credenziali dell utente usando il protocollo SASL, sul quale sono implementati diversi meccanismi (GSSAPI tramite Globus/GSI, AFS password, SSH key, certificati X.509 e AliEn tokens). In seguito al successo dell autenticazione il Proxy Service provvede ad abilitare l utente per l accesso alle risorse a cui a diritto, per un periodo limitato di tempo. Resource Broker: È il servizio che gestisce la coda dei jobs di AliEn, che sono descritti seguendo

42 2.4. ALIEN 35 le specifiche JDL (Job Description Language) di Condor ClassAds. Il Broker analizza le necessità dei lavori sottomessi (file di input, output,...) e se necessario modifica il JDL per definire esattamente la locazione dei file, comprese le eventuali repliche, necessarie per l esecuzione. A questo punto il Broker si occupa di mandare in esecuzione i job in uno dei siti che risulta idoneo alle specifiche JDL. Per effettuare quest operazione esistono, come detto in precedenza per glite, due modelli di funzionamento possibili il push e il pull. Figura 2.21: Pull Model di ALiEn AliEn adotta il Pull Model (fig.2.21), che permette al Broker di non conoscere lo stato del sistema demandandolo ai suoi Computing Element, che gli devono comunicare lo stato in cui si trovano. A questo punto il Broker provvede a distribuire i jobs sulle risorse disponibili, permettendo una buona flessibilità del sistema, che risulta avere una buona tolleranza ai guasti. Il meccanismo gestito dal Resource Broker coinvolge tre entità fondamentali di una VO: Computing Element, Storage Element e File Transfer. Il primo, come accennato poco sopra, agisce da interfaccia per il sistema batch locale, ovvero dialoga con il CPU Server (dove risiede il Broker) e una volta prelevati i JDL dei job, li traduce per il sistema batch locale (PBS, SGE, LSF, ecc...). Lo Storage Element si occupa invece della gestione dei file e della cache temporanea, appoggiandosi al File Transfer. Questo usa l FTD (File Transfer Daemon), e permette di spostare i files necessari per l esecuzione da e verso il Computing Element che ha preso in gestione il job (tutte le operazioni sono autenticate). Monitorizzazione: Questo Servizio è fornito dal Software MonaLisa, che raccoglie tutte le informazioni relative allo stato della griglia e le visualizza su pagine Web. Questo permette grazie ad una visione globale delle prestazioni di poter raggiungere un ottimizzazione e comprendere le reali Performance del sistema. Logger: È il meccanismo che riporta lo stato, compresa la condizione di errore, di tutti

43 36 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN ALICE Grid Monitoring with MonALISA - World map 27/05/ :27 PM MonALISA Repository for ALICE Repository Home Administration Section ALICE Reports Events XML Feed Firefox Toolbar MonaLisa GUI ALICE Repository ALICE Repository Google Map MonALISA Map Running trend Job Information SE Information Services Network Traffic FTD Transfers CAF Monitoring SHUTTLE LCG exp. monitoring Build system close all Current page Running jobs trend Running jobs trend 24h 12h 6h 1h (click arrows for detailed view) Running Jobs Zombie Jobs No Active Jobs ML Service Down Show xrootd transfers Show site relations Actions: Left Click - Zoom In Right Click - Zoom Out (Center on the mouse position) Zoom / Translation Factor: Image size: Adaptive Select Predefined Map: Europe Repository Home ALICE Web Page ALICE Clusters Contact CERN Copyright ALICE EXPERIMENT Figura 2.22: MonALISA Sistema di Monitoring di ALiEn i servizi. Questo permette al Grid Manager di monitorare tutte le eccezioni e correggerle dove possibile. Interfaccia (Software ad alto livello) Dopo aver descritto le componenti principali che costituiscono AliEn, l ultimo aspetto da analizzare sono le interfacce a disposizione dell utente per interagire con la GRID. Ad esempio il File Catalogue mette a disposizione sia una linea di comando che una maschera grafica per accedervi, sottomettere job e recuperare Pagina 1 di 1 i risultati. Un ulteriore modalità di accesso si ha attraverso il Portale Web, dal quale si può, oltre alle opzioni precedenti, accedere al pannello di controllo per amministrare e monitorare i servizi di una VO. Un alra importante via di accesso ai servizi della GRID è rappresentata dalle C/C++ API, che permettono l accesso a livello applicativo. In particolare quelle relative al C++ sono usate per facilitare l accesso al file system creato sulla base dell AliEn File Catalogue. Alienfs è stato implementato seguendo lo schema di LUFS (Linux Userland File System) (fig.??). Un utente unix deve solo fare un mount e un autenticazione alla GRID per poterlo usare come un file sytem locale. Ovviamente questo servizio, come tutti i servizi della GRID, sono e rimangono attivi previa autenticazione dell utente.

44 3 Installazione Procediamo adesso a descrivere i passi effettuati per preparare l ambiente per la realizzazione di un architettura GRID presso il dipartimento di Matematica U.Dini di Firenze. Il progetto prevede in una prima fase la sola installazione di più istanze del Globus Toolkit 4 (GT4) per studiarne il sistema di autenticazione e sperimentare una soluzione alternativa: Sostitire il sistema di autenticazione basato sulle Certification Authority con un sistema di autenticazione realizzato con Kerberos e il protocollo X.509. La fase successiva è composta dall installazione e configurazione di un ambiente GRID reale e funzionante: AliEn al quale sia possibile prospettare questo tipo di modifica. Il progetto prevede l installazione dei software tipici di un sistema GRID standard: un file system distribuito (AFS) un sistema di autenticazione Kerberos più istanze del Globus Toolkit 4 e di alcuni servizi che esulano dallo standard GRID e costituiscono pertanto la base dei test di questa tesi: un sistema batch SGE una certification authority basata su Kerberos un sistema di macchine virtualizzate con Xen

45 38 CAPITOLO 3. INSTALLAZIONE Per l installazione di queste componenti è stato necessario comporre un insieme di macchine dedicate, di cui è stato possibile ridimensionare il numero fisico grazie alla virtualizzazione Xen. L hardware messo gentilmente a disposizione dal dipartimento di Matematica si compone di quattro elementi tra cui due Dual Xeon, un Opetron e un Pentium III. Su queste macchine è stato installato il sistema di virtualizzazione Xen, dal quale originano quattro elementi: olmio.math.unifi.it, disprosio.math.unifi.it, itterbio.math.unifi.it e terbio.math.unifi.it. L Opteron, tulio.math.unifi.it, è stato utilizzato come macchina di servizio per l autenticazione e lo storage distribuito (KDC e AFS). Il Pentum III, erbio.math.unifi.it ospita un WN (Worker Node) di AliEn, ma principalmente è stato usato per le operazioni di test tra KCA e Globus. Figura 3.1: Sala Macchine Dipartimento di Matematica U. Dini Il sistema di virtualizzazione Xen ci ha permesso di provare installazioni di sistemi diversi osservandone le prestazioni mentre erano in esecuzione contemporaneamente, oltre che di ridurre il numero fisico di macchine (non decisivo in questo caso dove era comunque accettabile). Questo ha facilitato i confronti e quindi le considerazioni che hanno guidato le scelte. La prima operazione è stata la scelta del sistema Linux da installare: Scientific Linux Cern 4 (SLC4 ) o Debian Etch. La prima risultava idonea soprattutto perchè sviluppata dal CERN e quindi con le configurazioni base ideate per le necessità di un sistema GRID; ovvero i servizi che il centro di ricerca europeo fornisce ai suoi ricercatori, tra i quali il file system

46 3.1. INSTALLAZIONE DI XEN 39 Figura 3.2: terbio.math.unifi.it, olmio.math.unifi.it e itterbio.math.unifi.it distribuito AFS e Kerbros V. Debian è stata reputata una valida alternativa in quanto permetteva di testare la compatibilità della GRID con sistemi diversi da SLC4 e soprattutto perchè compatibile con le versioni più recenti di AFS, Kerberos, Xen che, come da tradizione Debian, sono in continuo e rapido aggiornamento. Dopo aver effettuato prove di installazioni su entrambe i sistemi, è stato scelto di installare Debian Etch, in quanto presentava meno problematiche per il mantenimento di uno stato consistente del sistema di virtualizzazione Xen. Andiamo ora a descrivere singolarmente l istallazione di ogni servizio. 3.1 Installazione di Xen L installazione del sistema di virtualizzazione Xen, vista l attuale simpatia che il mondo informatico gli riserva, è risultata più semplice del previsto. Il mondo Debian, come sua regola, anche a distanza di poche settimane ha fornito aggiornamenti migliorando così la stabilità e fornendo la possibilità di una gestione semplice e efficace delle macchine virtuali. Le macchine su cui è stato installato Xen 3.0 hanno le seguenti caratteristiche: gadolinio:~# uname -a Linux gadolinio xen-686 #1 SMP Thu May 10 03:24:35 UTC 2007 i686 gadolinio:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 1.60GHz stepping : 6 cpu MHz :

47 40 CAPITOLO 3. INSTALLAZIONE Figura 3.3: erbio.math.unifi.it e tulio.math.unifi.it cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Per prima cosa è stato installato il sistema Linux Debian Etch classico senza componenti grafiche come Xorg o XFree86, in modo da non appesantire il carico delle macchine e limitare i problemi legati alla sicurezza che le interfacce grafiche sono solite portare. Una volta che Debian è stata installata e configurata, appoggiandosi al suo sistema di gestione dei,apt, si procede a installare: apt-get install xen-linux-system xen-68 apt-get install libc6-xen apt-get install bridge-utils xen-tool per ottenere un sistema di virtualizzazione. Per renderlo definitivamente attivo si deve controllare che il sistema di boot, ad esempio GRUB contenga la seguente sezione

48 3.1. INSTALLAZIONE DI XEN 41 title root kernel module module Xen Debian GNU/Linux, kernel xen-686 (hd0,1) /boot/xen i386-pae.gz dom0_mem=128m /boot/vmlinuz xen-686 root=/dev/md0 ro console=tty0 /boot/initrd.img xen-686 e quindi si avvia la macchina fisica con il kernel contenente la patch di Xen, le cui funzioni sono state descritte in 2.1. Dopo il reboot del dom0, macchina fisica, è attivo il demone xend che fornisce un tool per monitorare le macchine virtuali. Per installare una macchina virtuale è necessario per prima cosa modificare il file di configurazione per abilitare il colegamento delle interfacce di rete virtuali alla corrispettiva fisica così da consentire ai domu, le istanze virtuali, l accesso alla rete come se fossero vere e propri computer indipendenti. A questo punto si prepara lo spazio fisico, un LVM, una partizione o un file immagine, dove si vuole installare il domue si procede creare un istanza virtualizzata di un altro sistema Debian con il comando: xen-create-image hostname disprosio.math.unifi.it -debootstrap ip= Al termine non si ha ancora una macchina virtuale, ma solo un istallazione Etch su uno spazio fisico; per poterla eseguire come domu si deve editare un file di configurazione specificando alcuni parametri in file di configurazione come nell esempio che segue: # Kernel + memory size kernel = /boot/vmlinuz xen-686 ramdisk = /boot/initrd.img xen-686 memory = 512 # Disk device(s). root= /dev/sda1 ro disk= [ phy:xen1/postfix-dom1-disk,sda1,w, phy:xen1/postfix-dom1-swap,sda2,w ] # Hostname name= disprosio.math.unifi.it # Networking vif = [ ip= ] # Behaviour on_poweroff = destroy on_reboot = restart on_crash= restar adesso con il comando: xm create -c file-di-configurazione

49 42 CAPITOLO 3. INSTALLAZIONE viene avviato il domu che risulta essere una normale debian senza alcuna differenza da un istallazione effettuata su una macchina fisica. Con questa procedura sono state creati i seguenti domu: disprosio.math.unifi.it, olmio.math.unifi.it e terbio.math.unifi.it. 3.2 Installazione di Kerberos e AFS Il primo passo è stato installare il sistema di autenticazione Kerberos V, in quanto questa scelta caratterizza le configurazioni delle installazioni di AFS e KCA, tutti servizi che risiedono sullo stesso computer, tulio.math.unifi.it, con le seguenti caratteristiche: tulio:~# uname -a Linux tulio amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux tulio:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping : 10 cpu MHz : cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp flags : yes : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up bogomips : TLB size : K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tulio:~# cat /proc/meminfo MemTotal: kb MemFree: kb Buffers: kb Cached: kb SwapCached: 0 kb Active: kb Inactive: kb HighTotal: 0 kb HighFree: 0 kb LowTotal: kb LowFree: kb

50 3.2. INSTALLAZIONE DI KERBEROS E AFS 43 SwapTotal: kb SwapFree: kb Dirty: 64 kb Writeback: 0 kb AnonPages: kb Mapped: kb Slab: kb PageTables: 1592 kb NFS_Unstable: 0 kb Bounce: 0 kb CommitLimit: kb Committed_AS: kb VmallocTotal: kb VmallocUsed: 4112 kb VmallocChunk: kb tulio:~# Il sistema installato su tulio, come su tutte le altre macchine del cluster, è una Debian Etch. I passi che descriverò per ottenere un istanza funzionante di Kerberos V, saranno abbastanza specifici per la distribuzione. I pacchetti necessari per installare Kerbros su un sistema debian con apt sono: apt-get install krb5-admin-server krb5-doc krb5-kdc krb5-user con questo semplice comando Kerberos è installato e funzionante, rimane solamente da configurarlo correttamente. I passi per la configurazione sono: 1. creare un REALM, che nel mio caso specifico sarà: GRID.MATH.UNIFI.IT 2. creare il databse di Kerberos ed un file per le ACL per accedervi 3. creare i principals necessari per autenticare l AFS e gli utenti nel sistema. Il primo step è la creazione del DB sono fatti automaticamente dall installer debian, per il secondo deve essere editato il file che si occupa di definire le ACL di default, in genere si trova in /etc/krb5kdc/kadm5.acl ed ha la seguente forma: tulio:~# cat /etc/krb5kdc/kadm5.acl */admin * tulio:~# In questo modo si specificano gli utenti che possono accedere al server Kerberos e con quali permessi, in questo caso tutti gli utenti il cui username termina in /admin hanno le credenziali di amministratori sul server tulio.math.unifi.it. Dopo queste operazioni è possibile connettersi al database e aggiungere gli account, denominati principals sotto kerberos. I comandi da usare sono kadmin.local per la connessione al database ed in seguito addprinc per per aggiungere gli utenti come ad esempio admin/admin con relativa password che sarà poi la password per accedere al sistema di storage distribuito AFS.

51 44 CAPITOLO 3. INSTALLAZIONE L ultima cosa da fare per rendere operativo il sistema di autenticzione Krb5 su tulio è creare correttamente il file di configurazione per il client, /etc/krb5.conf, specificando le coordinate per raggiungere il server, come si può vedere nell esempio che segue: [libdefaults] default_realm = GRID.MATH.UNIFI.IT # The following krb5.conf variables are only for MIT Kerberos. krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] GRID.MATH.UNIFI.IT = { kdc = tulio.math.unifi.it admin_server = tulio.math.unifi.it } [domain_realm] math.unifi.it = GRID.MATH.UNIFI.IT.math.unifi.it = GRID.MATH.UNIFI.IT grid.math.unifi.it = GRID.MATH.UNIFI.IT.grid.math.unifi.it = GRID.MATH.UNIFI.IT [login] krb4_convert = true krb4_get_tickets = false Per l installazione del client servono solamente i pacchetti: krb5-clientse krb5-user Installazione AFS Come per Kerberos anche i pacchetti per l installazione dell Andrew File System sono forniti da Debian; è infatti sufficente eseguire il seguente comando apt-get install openafs-fileserver openafs-krb5 che risolve e installa tutte le dipendenze tra cui: openafs-client, openafs-modulessource. Quest ultimi sono i pacchetti che devono essere installati anche sulle macchine client. Dopo l installazione per rendere operativo il software, deve essere configurata la nuova cella e compilato il modulo openafs per ottenere la compatibilità del kernel linux e permettergli di fare il mount delle partizioni AFS. Per prima cosa si indica il nome della cella bos setcellname tulio grid.math.unifi.it -noauth

52 3.2. INSTALLAZIONE DI KERBEROS E AFS 45 e si avviano i servizi ptserver e vlserver : bos create tulio <servizio> simple /usr/afs/bin/<servizio> -cell grid.math.unifi.it -noauth. Si aggiunge l utente kerberos admin/admin come admin nell user list di AFS: bos adduser tulio admin/admin -cell grid.math.unifi.it -noauth bos addkey tulio -kvno 0 -cell grid.math.unifi.it -noauth pts cu -name admin -cell grid.math.unifi.it -noauth pts adduser admin system:administrators -cell grid.math.unifi.it -noauth come ultima cosa rimane da configurare il fileserver (fs) e il volume principale (root.afs): bos create tulio fs fs fileserver volserver salvager -cell grid.math.unifi.it -noauth vos create tulio /vicepa root.afs -cell grid.math.unifi.it -noauth la partizione /vicepa è la partizione fisica, formattata ext3, su cui viene creata la cella. A questo punto il server è configurato, rimane solamente da rendere operativo il client. Carichiamo il modulo del kernel compilato precedentemente e si creano due directory dove poter fare il mount del file system distribuito, ovvero: taylor:~# mkdir /afs} taylor:~# mkdir /usr/vice/cache} e si avvia il servizio ottenendo il seguente output: tulio:~# /etc/init.d/openafs-client start Starting AFS services: openafs afsd. afsd: All AFS daemons started. tulio:~# mount /dev/sda3 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda7 on /vicepa type ext3 (rw,errors=remount-ro) AFS on /afs type afs (rw) tulio:~# Per rendere realmente operativa la cella grid.math.unifi.it manca ancora da configurare i permessi per l accesso e i mount point per i volumi che si desidera creare su AFS, ad esempio il volume per le home degli utenti e quello relativo ai servizi sul quale installeremo il sistema batch SGE. La procedura seguita è la seguente:

53 46 CAPITOLO 3. INSTALLAZIONE tulio:~# vos create tulio /vicepa root.cell Volume created on partition /vicepa of tulio taylor:~# fs mkm /afs/grid.math.unifi.it root.cell tulio:~# fs sa /afs/grid.math.unifi.it system:anyuser rl tulio:/afs/grid.math.unifi.it# vos create tulio /vicepa user Volume created on partition /vicepa of tulio tulio:/afs/grid.math.unifi.it# /usr/afs/bin/vos create tulio /vicepa service Volume created on partition /vicepa of tulio tulio:/afs/grid.math.unifi.it# fs mkm /afs/grid.math.unifi.it/users user tulio:/afs/grid.math.unifi.it# fs sa /afs/grid.math.unifi.it/users/ system:authuser rl tulio:/afs/grid.math.unifi.it# fs mkm /afs/grid.math.unifi.it/service service tulio:/afs/grid.math.unifi.it# fs sa /afs/grid.math.unifi.it/service/ system:authuser rl tulio:/afs/grid.math.unifi.it# ls service users tulio:/afs/grid.math.unifi.it# Terminata la configurazione i passi per accedere al servizio si storage distribuito sono: 1. prendere le credenziali Kerberos (kinit) 2. ottenere il ticket per accedere AFS (aklog) che è a tutti gli effetti un sevizio kerberized (2.2.1) come vediamo nell esempio seguente, dove si ottengono i permessi per accedere e si visualizza lo stato dell Andrew File System: tulio:~# kinit -k admin/admin tulio:~# aklog tulio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/22/07 18:00:14 07/23/07 18:00:14 07/22/07 18:00:18 07/23/07 18:00:14 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached tulio:~# bos status tulio Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance fs, currently running normally. Auxiliary status is: file server running. tulio:~# tulio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal:

54 3.3. INSTALLAZIONE DI KCA & KX Valid starting Expires Service principal 07/13/07 11:35:37 07/14/07 11:35:37 07/13/07 11:35:41 07/14/07 11:35:37 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached tulio:~# 3.3 Installazione di KCA & Kx509 Il software che implementa il servizio di Certificaition Authority basato su ticket Kerberos, detto KCA, non rientra tra i pacchetti che Debian fornisce con il tool apt. Come specificato in 2.2.3, KCA e Kx509 sono progetti sviluppati da University of Michigan. Per installarlo si devono recuperare i sorgenti da e compilarli. Prima di procedere alla compilazione è stato necessario modificare il codice, in quanto in fase di compilazione generava errori relativi ad una funzione openssl, iptos(ntohl(peeraddr.sin_addr.s_addr),ipstore)), che era stata richiamata con una sintassi obsoleta. Effettuata la modifica, la procedura d installazione non ha presentato ulteriori problemi. I passi seguiti per ottenere i una kca funzionante sono stati:./configure enable-server make make install creare una coppia Private Key/Certificate per identificare la CA un file che contenente un seriale per identificare univocamente i certificati generati un file di configurazione, kca.conf configurare il DNS, Domain Name Server, in modo da raggiungere il servizio di KCA La fase più importante è stata senza dubbio creare una configurazione che fosse ottimale per la collaborazione con il Globus Toolkit 4. Insieme ai sorgenti viene distribuito uno script che permette di creare la coppia Private Key/Certificate senza incorrere in errori. Prima di eseguire lo script,./mkcacert.sh, andando a modificare la parte iniziale si può specificare la directory dei file di configurazione e dove risiede il comando openssl necessario per portare a buon fine questa operazione. #!/bin/sh ## ## mkcert.sh -- Make SSL Certificate Files for make certificate command ## Copyright (c) 1998 Ralf S. Engelschall, All Rights Reserved. ## # parameters configdir="/srv/kca/conf" # Configuration directory

55 48 CAPITOLO 3. INSTALLAZIONE openssl="/usr/bin/openssl" extdir="/srv/kca" # Path to the openssl program # Directory where to find extfile.ca... Lanciato lo script, dopo aver generato la chiave e prima di generare il certificato associato, chiede di specificare le informazioni da includere nel certificato che identificheranno la Certification Authority: Country Name (2 letter code) [IT]: State or Province Name (full name) [Italy]: Locality (eg, city) [Florence]: Organization Name (eg, company) [Dip. di Matematica U.Dini - Univ. Firenze]: Common Name (eg, FQDN) [grid.math.unifi.it]: Nome della CA Ottenendo così un certificato collegato alla chiave appena generata con il seguente subject: /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/CN=grid.math.unifi.it A questo punto nella directory specificata, /srv/kca/conf, abbiamo il certificato e la chiave, mancano solo il seriale e il file di configurazione necessario per avviare il servizio. Per il primo è sufficiente creare un file serial con scritto all interno la stringa 01 ; per il secondo servono più operazioni. È necessario creare un keytab file per il servizio KCA generato da Kerberos V installato su tulio.math.unifi.it così da permettere a KCA di accedere al database Kerberos senza dover immetere alcuna password, passo essenziale in quanto la KCA deve lavorare come servizio kerberized. Fatta questa operazione manca solamente da creare il file di configurazione dove si specificano le coordinate dei certificati, del keytab file, la politica di gestione dei numeri seriali associati ai certificati e il dominio a cui appartiene la KCA, come si vede nell esempio riportato: # # KCA Configuration file # [ ca ] default_ca = CA_default # "CA_default" # # "default_ca" is the name of the default CA section of the config file # [ CA_default ] logfile_name = /srv/kca/log/kca.log # "/var/kca/kca.log" serial = /srv/kca/serial # "/var/https/test/ssl/kca_serial" sn_increment = 1 # "1" certificate = /srv/kca/conf/grid_cert.crt # "/var/kca/conf/kca.crt" private_key = /srv/kca/conf/grid_cert.key # "/var/kca/conf/kca.key" _domain = GRID.MATH.UNIFI.IT # <User s authentication realm> [ kx509 ] keytab = /srv/kca/conf/kca.keytab # "/var/kca/kca_service.keytab"

56 3.3. INSTALLAZIONE DI KCA & KX Per poter usufruire dei servizi della KCA manca solamente da aggiornare il DNS, dove si deve aggiungere la seguente riga al file relativo al dominio di interesse della KCA _kca._udp.grid.math.unifi.it. IN SRV tulio Dopo questo la configurazione è finita rimane solamente da lanciare il servizio in background: kca -c /srv/kca/kca.conf & Per quanto riguarda i client, è necessario solamente copiare gli eseguibili kx509 e kxlist, generati in fase di compilazione, sulle macchine che possiedono il client kerberos e sono configurate per raggiungere il realm grid.math.unifi.it. Di seguito riporto come esempio la successione di comandi per generare un certificato da credenziali kerbereos. disprosio:~# kinit gorini Password for disprosio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/26/07 15:22:50 07/27/07 15:22:50 renew until 07/26/07 15:22:50 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached disprosio:~# kx509 disprosio:~# kxlist Service kx509/certificate issuer= /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/CN=grid.math.unifi.it subject= /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/OU=grid.math.unifi.it serial=25 hash=fa65a93d disprosio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/26/07 15:22:50 07/27/07 15:22:50 renew until 07/26/07 15:22:50 07/26/07 15:23:01 07/27/07 15:22:50 renew until 07/26/07 15:22:50 07/25/07 15:23:01 07/27/07 15:22:50 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached disprosio:~#

57 50 CAPITOLO 3. INSTALLAZIONE 3.4 Installazione di un sistema batch: SGE Per soddisfare i requisiti di un installazione di AliEn Grid è risultato necessario installare sulla macchina che ospita il Computing Element, terbio.math.unifi.it, un sistema per la gestione di un cluster, che attualmente si compone di due macchine, ma che potenzialmente può ospitare un numero arbitrario di macchine. Il sistema batch scelto è quello sviluppato da Sun: SGE (Sun Grid Engine). La scelta è ricaduta su questo prodotto non solo per meriti specifici ma principalmente perchè è un prodotto Open Source, mentre la maggior parte degli altri supportati da Globus e quindi da AliEn sono sotto licenza proprietaria. L installazione di questo sistema batch è stata fatta sulla macchina virtuale con le seguenti specifiche: terbio:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 2.00GHz stepping : 7 cpu MHz : cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Il software si può scaricare gratuitamente su scegliendo i binari a seconda dell architettura su cui deve essere instalato. Una volta recuperato il binario si crea una directory che diventerà il valore della variabile d ambiente SGE_ROOT, e vi si decomprime il contenuto del pacchetto. Fondamentale per l installazione è che la directory sia condivisa con i computer che avranno la funzione di nodi di esecuzione, nel nostro caso la directory SGE_ROOT per terbio.math.unifi.it risiede su AFS viene dunque montata da tutte le macchine del cluster. Con i binari viene fornito uno script per gestire il processo di installazione. Infatti eseguendo il file./install_qmaster vengono richieste le informazioni necessarie per la configurazione che si vuole dare al cluster e al termine si ottiene un istanza funzionante del qmaster di SGE, ovvero il processo che gestisce le code di esecuzione. Per rendere totalmente operativo il sistema rimane da installare il processo che permette alla macchina di agire come execution node per il cluster. Anche questo passo di installazione è assistito da uno script,./install_execd che richiede un qmaster attivo per poter essere eseguito correttamente. Questa procedura ha quindi portato ad ottenere un sistema SGE completo e funzionante al quale è possibile aggiungere nodi eseguendo solo il passo relativo all execd. Infatti al qmaster è

58 3.5. INSTALLAZIONE DI GLOBUS 51 stato affiancato un Worker Node di AliEn che lavora come un execution node di SGE, erbio.math.unifi.it, come si vede nell esempio che segue dove eseguendo il comando qstat -f è possibile controllare lo stato dei nodi SGE e delle code di esecuzione. ~]$ qstat -f queuename qtype used/tot. load_avg arch states BIP 1/ lx24-x86 a AliEn.JobA aliprod r 07/27/ :28: BIP 1/ lx24-x AliEn.JobA aliprod r 07/27/ :09:29 1 ############################################################################ - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS ############################################################################ AliEn.JobA aliprod qw 07/24/ :52: AliEn.JobA aliprod qw 07/25/ :20: AliEn.JobA aliprod qw 07/25/ :57: AliEn.JobA aliprod qw 07/26/ :00: AliEn.JobA aliprod qw 07/26/ :03: AliEn.JobA aliprod qw 07/27/ :26: AliEn.JobA aliprod qw 07/27/ :30: AliEn.JobA aliprod qw 07/27/ :09:29 1 ~]$ qselect ~]$ 3.5 Installazione di Globus L installazione di Globus è stata sicuramente la più delicata, in quanto ci sono molte componenti che devono coesistere per rendere possibile la collaborazione di più istanze e quindi di più computer. Le macchine su cui ho installato il Globus Toolkit sono virtuali e tutte con le seguenti caratteristiche: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 1.60GHz stepping : 6 cpu MHz : cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes

59 52 CAPITOLO 3. INSTALLAZIONE fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Su queste macchine si è dovuto installare i seguenti programmi che sono considerati prerequisiti da [1]: zlib, J2SE SDK, apache-ant, gcc, g++, tar, sed, make, sudo, perl, postgres e libiodbc. Ci sono due strade per installare GT4: compilare tutti i sorgenti installare i binari specifici per la distribuizione e l architettura che si usa, ovviamente se questi sono presenti su, Le prime prove di installazione le ho fatte partendo dai sorgenti in quanto stavo effettuando delle prove su la distribuzione del CERN, SLC3. In seguito alla scelta di creare il pool di macchine con Debian, ho ritenuto più opportuno adottare i binary forniti dalla Globus Alliance. Ho quindi scaricato i pacchetti tar.gz relativi e li ho scompattati in una directory nella nella home di globus, che deve risultare il proprietario di tutti i file relativi al globus toolkit. Quindi ho creato la directory dove poi ho installato il software del toolkit, /usr/local/globus-4.0.5/. A questo punto ho eseguito esattament egli stessi pasi che si devono seguire installando il globus da sorgenti: 1. cd /home/globus/gt4.0.5-x86_deb_3.1-installer 2. export ANT_HOME=/usr/local/apache-ant export JAVA_HOME=/usr/java/j2sdk1.4.2_10/ 4. export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$PATH 5../configure prefix=/usr/local/globus-4.0.5/ with-iodbc=/usr/lib 6. make 7. make install Rispetto all installazione da sorgenti ho risparmiato del tempo in quanto i programmi erano già compilati per la distribuzione. Sono quindi passato alla parte più delicata la configurazione Configurazione della Security Per quanto riguarda la sicurezza come prima configurazione ho preferito adottare la CA suggerrita da [1] e quindi seguire lo schema di installazione della simpleca fornita insieme a Globus. Dopo aver impostato la variabile d ambiente export GLOBUS_LOCATION=/usr/local/globus-4.0.5

60 3.5. INSTALLAZIONE DI GLOBUS 53 e caricato l ambiente di globus mediante il comando source $GLOBUS_LOCATION/etc/globus-user-env.sh si richiama il setup della CA contenuta nel pacchetto di software che compone Globus $GLOBUS_LOCATION/setup/globus/setup-simple-ca Questo dopo aver richiesto la specifica di due parametri, password di certificato per la CA e l dell amministratore, provvede a generare la coppia chiave/certificato con cui firmare tutti i certificati che saranno generati. Al termine di questa procedura, viene richiesto di eseguire il setup-gsi del pacchetto Globus appena generato e installato. Questo passo però deve essere eseguito con i permessi di super utente, in quanto deve modificare tutte le componenti relative alla sicurezza specificate in GSI, ovvero eseguendo questo comando $GLOBUS_LOCATION/setup/globus_simple_ca_ebb88ce5_setup/setup-gsi -default viene creata la struttura di directory per la grid-security e i file contenenti le configurazioni per interfacciarsi alla simple CA per ottenere le creedenziali per accedere al sistema. Affinchè la Certification Authority creata e riconosciuta dal Toolkit risulti operativa deve essere creato un certificato host per la macchina che ospita la CA. Questo viene eseguito in tre passi: grid-cert-request -host hostname grid-ca-sign -in /etc/grid-security/hostcert_request.pem -out hostsigned.pem copiare il certificato firmato in /etc/grid-security e rinominare chiave e certificato come containerkey.pem e containercert.pem Configurazione del GridFTP, RFT e GRAM Dopo aver configurato la sicurezza di Globus è possibie completare l installazione del Toolkit inizializzando i servizi GridFTP, RFT e GRAM, necessari per lo spostamento dei file e per la scelta delle risorse coinvolte nel processo sottomesso alla GRID. Per quanto riguarda il GridFTP i passi per far partire il servizio sono due: inserire la riga relativo a questo servizio nel file relativo ai servizi, /etc/services e creare il seguente script per permettere al programma xinetd di avviare il servizio scrivendo /etc(init.d/xinetd reload. service gsiftp { instances = 100 socket_type = stream wait = no user = root env += GLOBUS_LOCATION=/usr/local/globus env += LD_LIBRARY_PATH=/usr/local/globus-4.0.5/lib server = /usr/local/globus-4.0.5/sbin/globus-gridftp-server server_args = -i

61 54 CAPITOLO 3. INSTALLAZIONE log_on_success += DURATION nice = 10 disable = no } A questo punto per completare la sezione che si occupa di trasferire i file si deve configurare l RFT, ovvero è stato configurato postgres ad accettare connessioni FTP per il database, rftdatabase, creato appositamente con gli script forniti dal toolkit. Dopo questo è stato possibile avviare il container ovvero tutto il pacchetto software installato con Globus, a meno del gestore delle risorse GRAM. Per avviare GRAM è bastato editare il file textsf/etc/sudoers con il comando visudo aggiungendo le seguenti righe: dopo di che riavviando il container tutti i servizi di Globus erano up and running. globus ALL=(gorini) NOPASSWD: /usr/local/globus-4.0.5/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.5/libexec/globus-job-manager-script.pl * globus ALL=(gorini) NOPASSWD: /usr/local/globus-4.0.5/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.1/libexec/globus-gram-local-proxy-tool * dove gorini è l utente che ho utilizzato per fare le prove di installazione. Ho ripetuto l installazione altre due volte con la sola differenza che in una, olmio.math.unifi.it, mi sono appoggiato alla simpleca già installata su disprosio.math.unifi.it (installazione appena descritta), mentre su itterbio.math.unifi.it ho installato un ulteriore CA in modo da poter ossevare il meccanismo di delegation Configurazione di WebMDS Per completare l installazione del Globus è stato configurato anche il sistema di monitoring fornito insieme al Toolkit, WebMDS. WebMDS è una servlet java che si interfaccia alle componenti di Globus, quali GRAM, RFT e GRIDFTP, appartenenti allo stesso gruppo di lavoro. L installazione consiste nel configurare un server Apache Tomcat su una delle macchine su cui è installata un istanza dei software GRID; nel nostro caso è stato scelto di installare il monitor su olmio.math.unifi.it, mentre la macchina adibita a raccogliere le informazioni a cui il WebMDS si rivolge per reperire informazioni è disprosio.math.unifi.it. Il risultato che si ottiene sono delle pagine web che monitorizzano lo stato delle macchine coinvolte nel gruppo di Globus, ovvero lo stato dei job elaborati in tutti i suoi aspetti. Di seguito sono riportati degli screenshot del WebMDS installato su olmio.math.unifi.it.

62 3.5. INSTALLAZIONE DI GLOBUS 55 Figura 3.4: Web MDS Main page Figura 3.5: Web MDS Group Detail

63 56 CAPITOLO 3. INSTALLAZIONE Service Group Entry Detail Service Group Entry Detail Service Group EPR Address: https:// :8443/wsrf/services/defaultindexserviceentry GroupKey: EntryKey: Member Service EPR Address: https:// :8443/wsrf/services/defaultindexservice Content AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: wssg:entry AggregatorData: Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/managedjobfactoryservice ReferenceProperties: ResourceID: Multi Content: type: ns5:aggregatorcontent AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: glue:gluece Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/managedjobfactoryservice ReferenceProperties: ResourceID: Fork Content: type: ns10:aggregatorcontent AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: glue:gluece AggregatorData: GLUECE: ComputingElement: Name: default UniqueID: default Info: GRAMVersion: HostName: olmio.math.unifi.it LRMSType: Fork LRMSVersion: 1.0 TotalCPUs: 1 State: EstimatedResponseTime: 0 FreeCPUs: 1 RunningJobs: 0 Status: enabled TotalJobs: 0 WaitingJobs: 0 WorstResponseTime: 0 Policy: MaxCPUTime: -1 MaxRunningJobs: -1 MaxTotalJobs: -1 MaxWallClockTime: -1 Priority: 0 Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/reliablefiletransferfactoryservice Content: type: ns15:aggregatorcontent AggregatorConfig: GetMultipleResourcePropertiesPollType: PollIntervalMillis: ResourcePropertyNames: rft:totalnumberofbytestransferred ResourcePropertyNames: rft:totalnumberofactivetransfers ResourcePropertyNames: rft:rftfactorystarttime ResourcePropertyNames: rft:activeresourceinstances ResourcePropertyNames: rft:totalnumberoftransfers Please report bugs and feature requests into the Globus Bugzilla. XSLT transformation provided by sgedetail.xsl version 1.4. Figura 3.6: Web MDS RFT Detail

64 4 Globus Delegation e KCA Prima di affrontare i concetti di sicurezza e di delegation che implementa Globus è fondamentale comprendere cosa significhi realmente stabilire una comunicazione sicura, che non si limita solo alla encryption e decryption dei dati coinvolti nella trasmissione. Una comunicazione per poter esser definita sicura deve rispecchiare queste tre caratteristiche: Privacy: Lo scambio di messaggi deve comunque rimanere privato, ovvero il messaggio deve essere leggibile solamente dagli interassati e non da intrusi che sono riusciti a intercettare il messaggio. Questo livello di sicurezza solitamente è raggiungibile con gli algoritmi di encryption/decryption. Integrity: Il messaggio inviato deve arrivare a destinazione senza subire alcuna modifca da parte di possibili intrusi. Questo è garantito grazie ad alcuni algoritmi di encrypting, come gli algoritmi di cifratura a chiave pubblica. Authentication: L identità coinvolte nella trasmissione devono essere certe, ovvero nessun intruso deve poter simulare uno dei due partecipanti alla comunicazione. Questo è garantito solo dagli algoritmi di encrypting più recenti. Spesso a questi parametri viene aggiunto un ulteriore punto per definire o meno una comunicazione sicura, l Authorization. Spesso confusa con l autenticazione (solo per affinità di suono, ma in realtà si riferisce ad un aspetto completamente diverso). L Autorizzazione infatti si occupa di definire cosa un utente autenticato può o non può fare. In un ambiente GRID la fase di Autorizzazione è tanto importante quanto gli altri aspetti, poichè gli utenti della griglia non possiedono gli stessi diritti. È evidente che per ottenere privacy, integrity e autentication è essenziale la Criptografia, che può essere definita come l arte di scrivere con caratteri segreti. È composta di due fasi: Encrypting, l azione di tradurre messaggi normali in in messaggi scritti con caratteri segreti (encrypted message) e Decrypting, ovvero tradurre i messaggi criptati in forma leggibile (unencrypted message). Gli algoritmi di crtittografia si dividono principalmente in due classi di algoritmi: Simmetrici la stessa chiave di cifratura è usata sia per cifrare che per decifrare

65 58 CAPITOLO 4. GLOBUS DELEGATION E KCA Asimettrici chiavi di cifratura diverse per cifrare e decifrare, l algoritmo a Chiave Pubblica è uno dei più usati di questa categoria. 4.1 Criptografia a Chiave Pubblica e X.509 Per coprire i requisiti elencati in precedenza e stabilire connessioni sicure il Globus Toolkit adotta un sistema di cifratura a chiave pubblica implementato con l uso dei certificati X.509 e connessioni SSL Criptografia a Chiave Publica L algoritmo di cifratura a chiave pubblica fa parte della classe ddegli algoritmi asimmetrici, quindi basato su due chiave chiavi, che vengono chiamate: Private Key conosciuta solo dal possesore Public Key conosciuta da tutti Figura 4.1: Ctittografia a Chiave Pubblica La relazione tra queste due chiavi è legata alla capacità che hanno di decifrare quello che l altra ha cifrato. Se il messaggio viene firmato con la chiave privata si è sicuri del mittente ma non che lo possa leggere un unico ricevente, mentre se si invia un messaggio criptato con la chiave pubblica siamo certi che lo leggerà solo chi possiede la chiave privata relativa, rispettando così il vincolo di privacy. La Crittografia a chiave pubblica basa la sua sicurezza sul fatto che ricavare la chiave privata conoscendo la pubblica è un problema, dall enorme costo computazionale, di non facile e rapida soluzione. Questo algoritmo presenta un grande svantaggio tipico della classe degli algoritmi asimmetrici, ovvero il calcolo è notevolmente più dispendioso e lungo rispetto agli algoritmi simmetrici. Di contro ha due aspetti vantaggiosi che risultano essenziali per ottenere e mantenere una connessione sicura. Il primo è non aver una necessità di mantenere una chiave comune tra i due partecipanti alla comunicazione; il secondo, ed anche il più significativo, è il fatto che la chiave pubblica, ripetto agli algoritmi simmetrici garantisce autenticazione e integrità oltre alla privacy.

66 4.1. CRIPTOGRAFIA A CHIAVE PUBBLICA E X Integrità L integrità nel sistema a chiave pubblica è garantita dalla firma digitale. La firma è di fatto una parte del messaggio che permette di capire se un messaggio ha subito modifiche durante la conversazione. Figura 4.2: Generazione di una Firma Digitale La firma digitale viene generata essenzialmente in due passi. Per prima cosa si crea un message digest, una somma del messaggio che si vuol trasmettere calcolata con un algoritmo di hashing che risulti sempre di dimensioni più piccole rispetto al messaggio e che cambi ad ogni minima modifica. Quindi si codifica con la chiave privata e si ottiene la firma digitale che viene inviata insieme al messaggio relativo. Il ricevente effettua le medesime operazioni, ovvero decodifica sia il testo che la firma, poi con lo stesso algoritmo crea il digest del messaggio che ha ricevuto e se risulta identico al digest associato al messaggio è certo che l integrità della comunicazione è stata preservata. Autenticazione La firma digitale contribuisce anche a garantire una weak authentication. Infatti se la relazione tra chiave pubblica e privata è rispettata siamo sicuri che il messaggio provenga da un determinato utente; è altrettanto vero però che questo non fornisce alcuna garanzia sulla possibilità che qualcuno possa impersonare il mandante. Applicando la firma digitale ai certificati, ovvero usando i certificati digitali, si ottengono le conferme cercate: che una determinata chiave sia veramente in possesso di un particolare utente Certificati X.509 La CA è l ente che gestisce il rilascio e garantisce le credenziali che queste forniscono, apponendo la firma su questi documenti come si vede nell esempio della figura 4.3. La firma della CA è ottenuta dalla sua chiave privata dalla quale si può verificare l integrità con la chiave pubblica applcando l algoritmo descritto in

67 60 CAPITOLO 4. GLOBUS DELEGATION E KCA Figura 4.3: Esempio di un certificato Digitale Tutto il meccanismo è fondato sulla fiducia, infatti il certificato digitale assume la funzione tipica di una firma digitale, confermando che il messaggio provenga da una determinata persona (meccanismo di chiave privata/pubblica); in più se la CA che ha firmato il certificato è trusted si ha anche la certezza che nessuno lo abbia usato impropriamente, ottenendo definitivamente la proprietà di autenticazione e di connessione sicura. Formato X.509 I certificati sono scritti secondo una codifica ben precisa: X.509. Un certificato X.509 è un file di testo che contiene numerose informazioni inserite secondo una precisa sintassi. Le informazioni che possono essere inserite sono molteplici ma quelle indispensabili per la funzione di un certificato sono quattro: - Subject : identifica il nome dell utente in un certificato codificato nel seguente modo, O=Università di Firenze, OU=Informatica, CN=Stefano Claudio Gorini dove : O identifica l organizzazione OU Unità specifica dell organizzazione CN il Common Name ovvero comunemente qui si trova il nome dell utente C il paese di appartenenza dell utente - Subject s Public Key indica la chiave e l algoritmo usato per clacolarla - Iusser s Subject indica la CA che ha rilasciato il certificato - Digital Signature è la firma digitale di tutte le informazioni contenute ne certificato generata con la chiave privata della CA. Quello che segue è un esempio reale di un certificato X.509 e come si può chiaramente vedere contiene molte altre informazioni, come la versione del formato X.509 utilizzata, il periodo in cui il certificato è considerato valido dalla CA. Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2)

68 4.2. GT4 DELEGATION 61 Signature Algorithm: md5withrsaencryption Issuer: O=Grid, OU=GlobusTest, OU=simpleCA-itterbio.math.unifi.it, CN=Globus Simple CA Validity Not Before: Jul 14 18:53: GMT Not After : Jul 13 18:53: GMT Subject: O=Grid, OU=GlobusTest, OU=simpleCA-itterbio.math.unifi.it, OU=math.unifi.it, CN=Gorini Stefano Claudio Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d2:6e:90:81:b5:0e:a2:db:fb:d4:89:3a:f8:e8: f6:8e:4b:5e:53:5a:1b:04:01:3a:f5:f5:34:14:15: ab:25:21:18:9b:d8:7c:62:4d:da:4a:38:14:06:50: b7:14:f9:d4:2f:42:8b:19:d5:6e:7d:0a:e5:49:f2: e7:78:fe:24:e6:99:8b:a0:02:24:dc:de:e5:66:de: b1:ae:6b:60:a1:c2:76:57:0d:13:21:e1:e1:63:ad: c5:ee:0a:56:50:17:cd:cd:b6:3a:36:b7:06:93:2d: 6c:d6:48:7b:ab:57:b4:aa:9d:d3:48:6b:04:ef:c1: 5e:76:07:21:65:3a:4c:1f:05 Exponent: (0x10001) X509v3 extensions: Netscape Cert Type: SSL Client, SSL Server, S/MIME, Object Signing Signature Algorithm: md5withrsaencryption 9c:22:59:2e:d1:e4:74:0a:7f:0d:ea:6b:98:c8:5d:64:b4:95: f5:c2:d3:92:c7:8d:46:50:c3:17:d9:0b:09:74:00:4d:37:6f: 04:b5:e1:a8:cb:2d:54:0f:01:00:28:57:f4:8d:9d:27:df:01: 21:8b:b9:88:05:c8:dd:40:b7:7c:d5:3f:24:7b:f1:be:7a:6f: 51:5d:79:dc:04:6e:57:d1:cf:43:dd:10:71:9a:f8:e5:df:80: Tutto il meccanismo dei certificati si basa sulla fiducia che gli utenti ripongono nelle Certificaion Authority. Un ultimo chiarimento è quindi necessario per coprendere a pieno il meccanismo dei certificati digitali. Le CA che firmano per gli utenti sono a loro volta identificate da n certificato che le distingue in due tipologie: self-signed CA, detta anche root, e not self-signed CA. La prima firma il proprio cerificato da sola richiedendo così che gli utenti si fidino direttamente di lei. La seconda, invece, è parte di una catena dove a partire da una self-signed CA, derivano numerose CA i cui certificati di identità sono sottoscritti dalla root o da una CA che gerarchicamente risiede al livello superiore (fig.4.4). La catena che si forma crea anche una catena di fiducia permettendo agli utenti di fidarsi anche di CA non direttamente conosciute ma che sono segnate come trustworthy. 4.2 GT4 Delegation La sicurezza, come riferito in 2.3, rappresenta uno degli aspetti fondamentali di un ambiente GRID. Anche il Globus Toolkit implementa un infrastruttura per gestire questo aspetto, GSI (Grid Security Infrastructure).

69 62 CAPITOLO 4. GLOBUS DELEGATION E KCA Figura 4.4: CA trustworthy Delegation e single sign-on Delegation e single sign-on rappresentano una delle funzionalità più importanti di GSI. Infatti in una Grid sono tipicamente coinvolte più organizzaioni ognuna con il proprio meccanismo di autenticazione e dover inserire più volte le proprie credenziali risulta un operazione scomda oltre che inutile. Infatti è notevolmente più comodo e veloce accredi- Figura 4.5: Delegation tarsi una volta e far si che le risorse della Grid siano in grado di passarsi le credenziali degli utenti. La tecnologia che permette la delega delle credenziali è il Proxy Certificate. Si definisce proxy come lo strumento con cui una persona ha il permesso di eseguire operazioni in vece di un altra (The instrument by which a person is empowered to transact the affairs of another, definizione del vocavolario Webster); il proxy forniscce certificati del tipo raffigurato in 4.6 per permette questo tipo di operazione. Il certificato rilasciato è valido in quanto firmato con la chiave privata del proxy, che è generata appositamente, in accordo tra le entità coinvolte. Una particolarità (anche questa visibile dalla fig.4.6) dei proxy certificate risiede nel limite temporale imposto all usabilità con la specifica di un lifetime. L introduzione di quest ulteriore livello che permette a qualcuno di aagire incondizinatamente in nome di un altro introduce ovviamente nuovi rischi; i lifetime permettono di limitare i danni, ma la vera difesa è rappresentata dalla possibilità di poter limitare l uso dei proxy solamente ad alcune attività. Si descrive ora brevemente il meccaniso che permette di usare il proxy certificate. Il processo di validazione di un certificato proxy è simile a quello descritto nelle sezioni

70 4.3. SIMPLE-CA E KCA 63 Figura 4.6: Un esempio di certificato rilasciato dal proxy precedente. La differenza principale è che il certificato non è firmato da alcuna CA, ma dall utente. Infatti nel certificato viene specificato il nome dell utente la cui chiave pubblica deve essere usata per testarne l autenticità. Figura 4.7: Un esempio di certificato rilasciato dal proxy Per ovviare al fatto che il ricevente possa non conoscere l utente che firma la delega, viene inviata insieme al proxy certificate anche il certificato dell utente coinvolto. Quest ultimo, come tutti i certificati X.509 è firmato da una Certification Authority, quindi per validare le credenziali del proxy si crea una catena, fig.4.7, di firme che riferiscono comunque ad una CA. La catena può comunque espandersi ulteriormente poichè niente impedisce ad un proxy di firmare un altro proxy e così via, permettendo così di ampliare maggiormente il meccanismo di delega. 4.3 simple-ca e KCA Come abbiamo visto nella sezioni precedenti la security di Globus è demandata ad un sistema di certificati SSL del tipo X.509. Nella sezione del capitolo 3 abbiamo specificato quale fosse il sistema installato di default sul Globus Toolkit, simple-ca.

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito:

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito: Autore : Giulio Martino IT Security, Network and Voice Manager Technical Writer e Supporter di ISAServer.it www.isaserver.it www.ocsserver.it www.voipexperts.it - blogs.dotnethell.it/isacab giulio.martino@isaserver.it

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it Sicurezza delle reti wireless Alberto Gianoli alberto.gianoli@fe.infn.it Concetti di base IEEE 802.11: famiglia di standard tra cui: 802.11a, b, g: physical e max data rate spec. 802.11e: QoS (traffic

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Rational Asset Manager, versione 7.1

Rational Asset Manager, versione 7.1 Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Note Prima di utilizzare queste informazioni e il prodotto

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Il World Wide Web: nozioni introduttive

Il World Wide Web: nozioni introduttive Il World Wide Web: nozioni introduttive Dott. Nicole NOVIELLI novielli@di.uniba.it http://www.di.uniba.it/intint/people/nicole.html Cos è Internet! Acronimo di "interconnected networks" ("reti interconnesse")!

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

IT Service Management, le best practice per la gestione dei servizi

IT Service Management, le best practice per la gestione dei servizi Il Framework ITIL e gli Standard di PMI : : possibili sinergie Milano, Venerdì, 11 Luglio 2008 IT Service Management, le best practice per la gestione dei servizi Maxime Sottini Slide 1 Agenda Introduzione

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING

MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING UN BUON MOTIVO PER [cod. E603] L obiettivo del corso è fornire le competenze e conoscenze

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi.

Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet Internet è universalmente nota come la Rete delle reti: un insieme smisurato di computer collegati tra loro per scambiarsi dati e servizi. Internet: la rete delle reti Alberto Ferrari Connessioni

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone Paragrafo 1 Prerequisiti Definizione di applicazione server Essa è un servizio che è in esecuzione su un server 1 al fine di essere disponibile per tutti gli host che lo richiedono. Esempi sono: il servizio

Dettagli

InitZero s.r.l. Via P. Calamandrei, 24-52100 Arezzo email: info@initzero.it

InitZero s.r.l. Via P. Calamandrei, 24-52100 Arezzo email: info@initzero.it izticket Il programma izticket permette la gestione delle chiamate di intervento tecnico. E un applicazione web, basata su un potente application server java, testata con i più diffusi browser (quali Firefox,

Dettagli

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONNECTING FIRST AND SECOND LIFE Università degli studi di Catania Facoltà di Ingegneria 26 Gennaio 2009 Sommario 1 Introduzione 2 Middleware Middleware:

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

Sizing di un infrastruttura server con VMware

Sizing di un infrastruttura server con VMware Sizing di un infrastruttura server con VMware v1.1 Matteo Cappelli Vediamo una serie di best practices per progettare e dimensionare un infrastruttura di server virtuali con VMware vsphere 5.0. Innanzitutto

Dettagli

Guida alla scansione su FTP

Guida alla scansione su FTP Guida alla scansione su FTP Per ottenere informazioni di base sulla rete e sulle funzionalità di rete avanzate della macchina Brother, consultare la uu Guida dell'utente in rete. Per ottenere informazioni

Dettagli

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1 Tutorial Configuration Managment Configurare il servizio EC2 su AWS Pagina 1 Sommario 1. INTRODUZIONE... 3 2. PROGRAMMI NECESSARI... 4 3. PANNELLO DI CONTROLLO... 5 4. CONFIGURARE E LANCIARE UN ISTANZA...

Dettagli

UNIVERSITÀ DEGLI STUDI DI PARMA

UNIVERSITÀ DEGLI STUDI DI PARMA UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA Tesi di laurea in RETI DI CALCOLATORI Autenticazione Centralizzata con il sistema CAS, integrando

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

Le caratteristiche di interoperabilità del Terrapack 32 M

Le caratteristiche di interoperabilità del Terrapack 32 M I T P E l e t t r o n i c a Le caratteristiche di interoperabilità del Terrapack 32 M M. Guerriero*, V. Ferrara**, L. de Santis*** * ITP Elettronica ** Dipartimento di Ingegneria Elettronica Univ. La Sapienza

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci Manuale di Remote Desktop Connection Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci 2 Indice 1 Introduzione 5 2 Il protocollo Remote Frame Buffer 6 3 Uso di Remote Desktop

Dettagli

Interfaccia Web per customizzare l interfaccia dei terminali e

Interfaccia Web per customizzare l interfaccia dei terminali e SIP - Session Initiation Protocol Il protocollo SIP (RFC 2543) è un protocollo di segnalazione e controllo in architettura peer-to-peer che opera al livello delle applicazioni e quindi sviluppato per stabilire

Dettagli

Active Solution & Systems illustra La virtualizzazione dei Server secondo il produttore di Storage Qsan

Active Solution & Systems illustra La virtualizzazione dei Server secondo il produttore di Storage Qsan Active Solution & Systems illustra La virtualizzazione dei secondo il produttore di Storage Qsan Milano, 9 Febbraio 2012 -Active Solution & Systems, società attiva sul mercato dal 1993, e da sempre alla

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Security Governance. Technet Security Day Milano/Roma 2007 NSEC Security Excellence Day Milano 2007. Feliciano Intini

Security Governance. Technet Security Day Milano/Roma 2007 NSEC Security Excellence Day Milano 2007. Feliciano Intini Technet Security Day Milano/Roma 2007 NSEC Security Excellence Day Milano 2007 Security Governance Chief Security Advisor Microsoft Italia feliciano.intini@microsoft.com http://blogs.technet.com/feliciano_intini

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore)

Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore) Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore) Autore: Matteo Veroni Email: matver87@gmail.com Sito web: matteoveroni@altervista.org Fonti consultate: http://openmeetings.apache.org/

Dettagli

progettiamo e realizziamo architetture informatiche Company Profile

progettiamo e realizziamo architetture informatiche Company Profile Company Profile Chi siamo Kammatech Consulting S.r.l. nasce nel 2000 con l'obiettivo di operare nel settore I.C.T., fornendo servizi di progettazione, realizzazione e manutenzione di reti aziendali. Nel

Dettagli

rischi del cloud computing

rischi del cloud computing rischi del cloud computing maurizio pizzonia dipartimento di informatica e automazione università degli studi roma tre 1 due tipologie di rischi rischi legati alla sicurezza informatica vulnerabilità affidabilità

Dettagli

Cinque best practice per amministratori VMware: Microsoft Exchange su VMware

Cinque best practice per amministratori VMware: Microsoft Exchange su VMware Cinque best practice per amministratori VMware: Microsoft Exchange su VMware Scott Lowe Founder and Managing Consultant del 1610 Group Modern Data Protection Built for Virtualization Introduzione C è stato

Dettagli

IT-BOOK. Domini Hosting Web marketing E-mail e PEC

IT-BOOK. Domini Hosting Web marketing E-mail e PEC 5 giugno 09 IT-BOOK Configurazioni e cartatteristiche tecniche possono essere soggette a variazioni senza preavviso. Tutti i marchi citati sono registrati dai rispettivi proprietari. Non gettare per terra:

Dettagli

Architettura di un sistema informatico 1 CONCETTI GENERALI

Architettura di un sistema informatico 1 CONCETTI GENERALI Architettura di un sistema informatico Realizzata dal Dott. Dino Feragalli 1 CONCETTI GENERALI 1.1 Obiettivi Il seguente progetto vuole descrivere l amministrazione dell ITC (Information Tecnology end

Dettagli

FileMaker Server 13. Guida introduttiva

FileMaker Server 13. Guida introduttiva FileMaker Server 13 Guida introduttiva 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 Stati Uniti FileMaker e Bento sono marchi

Dettagli

Agilent OpenLAB Chromatography Data System (CDS)

Agilent OpenLAB Chromatography Data System (CDS) Agilent OpenLAB Chromatography Data System (CDS) EZChrom Edition e ChemStation Edition Requisiti hardware e software Agilent Technologies Informazioni legali Agilent Technologies, Inc. 2013 Nessuna parte

Dettagli

Enterprise Services Infrastructure ESI 2.0

Enterprise Services Infrastructure ESI 2.0 Enterprise Services Infrastructure ESI 2.0 Caratteristiche e Posizionamento ver. 2.1 del 21/01/2013 Cos è ESI - Enterprise Service Infrastructure? Cos è ESI? ESI (Enteprise Service Infrastructure) è una

Dettagli

Cos è un protocollo? Ciao. Ciao 2:00. tempo. Un protocollo umano e un protocollo di reti di computer:

Cos è un protocollo? Ciao. Ciao 2:00. <file> tempo. Un protocollo umano e un protocollo di reti di computer: Cos è un protocollo? Un protocollo umano e un protocollo di reti di computer: Ciao Ciao Hai l ora? 2:00 tempo TCP connection request TCP connection reply. Get http://www.di.unito.it/index.htm Domanda:

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Virtualizzazione con Microsoft Tecnologie e Licensing

Virtualizzazione con Microsoft Tecnologie e Licensing Microsoft Virtualizzazione con Microsoft Tecnologie e Licensing Profile Redirezione dei documenti Offline files Server Presentation Management Desktop Windows Vista Enterprise Centralized Desktop Application

Dettagli

Reti di Telecomunicazione Lezione 7

Reti di Telecomunicazione Lezione 7 Reti di Telecomunicazione Lezione 7 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Il protocollo Programma della lezione file transfer protocol descrizione architetturale descrizione

Dettagli

CORPORATE OVERVIEW. www.akhela.com

CORPORATE OVERVIEW. www.akhela.com CORPORATE OVERVIEW www.akhela.com BRIDGE THE GAP CORPORATE OVERVIEW Bridge the gap Akhela è un azienda IT innovativa che offre al mercato servizi e soluzioni Cloud Based che aiutano le aziende a colmare

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

F O R M A T O E U R O P E O

F O R M A T O E U R O P E O F O R M A T O E U R O P E O P E R I L C U R R I C U L U M V I T A E INFORMAZIONI PERSONALI Nome Indirizzo Laura Bacci, PMP Via Tezze, 36 46100 MANTOVA Telefono (+39) 348 6947997 Fax (+39) 0376 1810801

Dettagli

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l.

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. Babel S.r.l. - P.zza S. Benedetto da Norcia 33, 00040 Pomezia (RM) www.babel.it

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

RedDot Content Management Server Content Management Server Non sottovalutate il potenziale della comunicazione online: usatela! RedDot CMS vi permette di... Implementare, gestire ed estendere progetti

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

Process mining & Optimization Un approccio matematico al problema

Process mining & Optimization Un approccio matematico al problema Res User Meeting 2014 con la partecipazione di Scriviamo insieme il futuro Paolo Ferrandi Responsabile Tecnico Research for Enterprise Systems Federico Bonelli Engineer Process mining & Optimization Un

Dettagli

Configurazione avanzata di IBM SPSS Modeler Entity Analytics

Configurazione avanzata di IBM SPSS Modeler Entity Analytics Configurazione avanzata di IBM SPSS Modeler Entity Analytics Introduzione I destinatari di questa guida sono gli amministratori di sistema che configurano IBM SPSS Modeler Entity Analytics (EA) in modo

Dettagli

DigitPA egovernment e Cloud computing

DigitPA egovernment e Cloud computing DigitPA egovernment e Cloud computing Esigenze ed esperienze dal punto di vista della domanda RELATORE: Francesco GERBINO 5 ottobre 2010 Agenda Presentazione della Società Le infrastrutture elaborative

Dettagli

Ambienti supportati. Configurazione della stampante di rete. Stampa. Gestione della carta. Manutenzione. Risoluzione dei problemi.

Ambienti supportati. Configurazione della stampante di rete. Stampa. Gestione della carta. Manutenzione. Risoluzione dei problemi. I server di stampa vengono utilizzati per collegare le stampanti alle reti. In tal modo, più utenti possono accedere alle stampanti dalle proprie workstation, condividendo sofisticate e costose risorse.

Dettagli

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Tobia Castaldi Alessandro Amirante Lorenzo Miniero Simon Pietro Romano Giorgio Ventre 02/10/2009 GARR 2009 "Network

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it ISO 9001: 2008 Profilo Aziendale METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it Sede legale: * Viale Brodolini, 117-60044 - Fabriano (AN) - Tel. 0732.251856 Sede amministrativa:

Dettagli

Boot Camp Guida all installazione e alla configurazione

Boot Camp Guida all installazione e alla configurazione Boot Camp Guida all installazione e alla configurazione Indice 4 Introduzione 5 Cosa ti occorre 6 Panoramica dell installazione 6 Passo 1: verifica la presenza di aggiornamenti. 6 Passo 2: apri Assistente

Dettagli

Guida al nuovo sistema di posta. CloudMail UCSC. (rev.doc. 1.4)

Guida al nuovo sistema di posta. CloudMail UCSC. (rev.doc. 1.4) Guida al nuovo sistema di posta CloudMail UCSC (rev.doc. 1.4) L Università per poter migliorare l utilizzo del sistema di posta adeguandolo agli standard funzionali più diffusi ha previsto la migrazione

Dettagli

Virtualizzazione e installazione Linux

Virtualizzazione e installazione Linux Virtualizzazione e installazione Linux Federico De Meo, Davide Quaglia, Simone Bronuzzi Lo scopo di questa esercitazione è quello di introdurre il concetto di virtualizzazione, di creare un ambiente virtuale

Dettagli

Guida Dell di base all'acquisto dei server

Guida Dell di base all'acquisto dei server Guida Dell di base all'acquisto dei server Per le piccole aziende che dispongono di più computer è opportuno investire in un server che aiuti a garantire la sicurezza e l'organizzazione dei dati, consentendo

Dettagli

SICUREZZA SENZA COMPROMESSI PER TUTTI GLI AMBIENTI VIRTUALI. Security for Virtual and Cloud Environments

SICUREZZA SENZA COMPROMESSI PER TUTTI GLI AMBIENTI VIRTUALI. Security for Virtual and Cloud Environments SICUREZZA SENZA COMPROMESSI PER TUTTI GLI AMBIENTI VIRTUALI Security for Virtual and Cloud Environments PROTEZIONE O PRESTAZIONI? Già nel 2009, il numero di macchine virtuali aveva superato quello dei

Dettagli

Mettere in sicurezza l infrastruttura dei desktop virtuali con Citrix NetScaler

Mettere in sicurezza l infrastruttura dei desktop virtuali con Citrix NetScaler Mettere in sicurezza l infrastruttura dei desktop virtuali con Citrix NetScaler 2 Le aziende attuali stanno adottando rapidamente la virtualizzazione desktop quale mezzo per ridurre i costi operativi,

Dettagli

SMARTCARD Studente: Elvis Ciotti Prof: Luciano Margara 1

SMARTCARD Studente: Elvis Ciotti Prof: Luciano Margara 1 SMARTCARD Studente: Elvis Ciotti Prof: Luciano Margara 1 Introduzione SmartCard: Carta intelligente Evoluzione della carta magnetica Simile a piccolo computer : contiene memoria (a contatti elettrici)

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

Ottimizzazione della gestione del data center con Microsoft System Center

Ottimizzazione della gestione del data center con Microsoft System Center Ottimizzazione della gestione del data center con Microsoft System Center Declinazione di responsabilità e informazioni sul copyright Le informazioni contenute nel presente documento rappresentano le conoscenze

Dettagli

Guida ai Servizi Internet per il Referente Aziendale

Guida ai Servizi Internet per il Referente Aziendale Guida ai Servizi Internet per il Referente Aziendale Indice Indice Introduzione...3 Guida al primo accesso...3 Accessi successivi...5 Amministrazione dei servizi avanzati (VAS)...6 Attivazione dei VAS...7

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it Zabbix 4 Dummies Dimitri Bellini, Zabbix Trainer Quadrata.it Relatore Nome: Biografia: Dimitri Bellini Decennale esperienza su sistemi operativi UX based, Storage Area Network, Array Management e tutto

Dettagli