INFN - Commissione Calcolo 

Progetto Directory Service

 

i partecipanti

documenti

documenti riservati 

verbali

messaggi

home page

 

dirserv@infn.it

07/15/99

 

 

 

 

 

 

                                    

 

 

 

Directory services: proposta di applicazione per l’INFN

 

 

 

C. Allocchio, L. dell’Agnello, L. Fonti, G. Lo Biondo, G. Vita Finzi

 

 

18 Maggio 1999

 

 

 

Introduzione

 

Le informazioni riguardanti l’utenza costituiscono sicuramente una base di dati utile sia per la consultazione che per il funzionamento dei sistemi informatici dell’INFN.

Attualmente pero` le informazioni necessarie per un certo numero di operazioni (gestione delle utenze, sistema di mailing, etc…) sono frazionate, scollegate tra di loro e hanno un formato spesso dissimile.

Infatti la gestione dei dati (es.: file di password, database alias per la posta, mailing list, chiavi pgp, elenchi telefonici, whois database, database dell’hardware) non e` razionalizzata causando una duplicazione delle informazioni , spesso incongruenti fra loro, e, in ultima analisi, una difficile reperibilita` ed utilizzo.

Uniformare i meccanismi di accesso e il formato dei dati significa avere una pił ampia a omogenea base per applicazioni di tipo diverso.

Oggetto di questa proposta e` quindi la creazione di un sistema informativo unico contenente i dati pubblici utili per lo svolgimento dell’attivita` degli utenti INFN.

 

 

Situazione attuale nell’INFN

Al momento i database contenti informazioni sull’utenza piu’ usati sono:

Passwd: contiene l’elenco degli utenti che hanno accesso ad un particolare calcolatore. La gestione e` a cura dell’amministratore del singolo host (quindi incontrollabile);
Yellow Pages (NIS): contiene l’elenco degli utenti che hanno accesso ad un gruppo di calcolatori. La gestione a livello di gruppo (incontrollabile);

 

Userdb (alias per il mail): contiene l’elenco degli indirizzi di posta elettronica degli utenti di ogni sezione. La gestione e` centralizzata a livello di sezione;

 

Chiavi pgp / certificati x-509: le chiavi PGP e i certificati X.509 vengono distribuiti centralmente (sez. di Firenze) e pubblicate sul web del gruppo della security;

 

Mailing list del dominio infn.it: esistono circa trenta liste create per comitati o gruppi di lavoro o commissioni scientifiche la cui gestione e’ centralizzata (CNAF). Esiste anche una mailing list generale estratta dal database WHOIS con i nominativi di tutto il personale.
Mailing list locali: a cura delle sezioni o del responsabile dell’attivita’. Senza controllo.

 

Elenchi telefonici locali: la gestione e` centralizzata a livello di sezione;

 

Whois database (anagrafica): contiene i nominativi e le informazioni per contattare tutto il personale dipendente e associato. La gestione e` centralizzata (CNAF) e l’aggiornamento dei dati e` demandato agli utenti. le informazioni in esso contenute sono spesso obsolete.

 

Inoltre esiste il database Luce (db hardware INFN), con gestione centralizzata (CNAF).

 

Soluzioni possibili

 

Obiettivo del progetto e’ quello di realizzare un sistema informativo integrato a livello nazionale.

Le soluzioni per raggiungere questo obiettivo sono molteplici; ad una prima analisi, anche in base anche all’esperienza maturata finora, due sembrano essere quelle piu` idonee.

Una prima possibilita` e` offerta dal database whois sviluppato a RIPE, attualmente utilizzato nell’INFN per l’anagrafica degli utenti.

La sua struttura permette di integrarlo facilmente con qualsiasi tipo di informazioni.

Per adesso manca pero` un’interfaccia standard che permetta un accesso diretto degli applicativi ai dati.

L’altra soluzione prevede invece l’uso di LDAP, uno standard (IETF draft standard protocol) sempre piu` diffuso anche commercialmente.

LDAP ha una struttura di database gerarchici, anche se puo` essere utilizzato come un database unico e centralizzato (esattamente come il whois database).

Anche LDAP permette l’integrazione in ciascuna entry (relativa ad un utente) di tutte le informazioni che si ritengono utili.

Al contrario pero` del database whois, un Directory Service (DS) come LDAP costituisce una base standard per lo sviluppo e l’utilizzo di applicazioni di tipo svariato che hanno necessita’ di accedere ad informazioni riguardanti l’utenza (es.: ricerca da un mailer dell’indirizzo di un utente, gestione delle utenze su un pool di macchine etc…).

E` chiaro che ognuna di queste due soluzioni offre vantaggi e svantaggi: il whois database e` un database centrale e cio` semplifica la gestione e la manutenzione del servizio; un DS come LDAP invece, comporta un onere iniziale per gli amministratori locali (installazione e configurazione), ma a medio termine rappresenta un grosso vantaggio per la gestione globale delle informazioni.

 

Evoluzione Sistemi Informativi in Ambiente HEP e Commerciale

 

La scelta di una soluzione come quella di un DS e` supportata dall’orientamento riscontrato sia in ambito HEP che in ambito commerciale.

Esistono infatti sistemi di produzione e proposte di evoluzione dei DS al CERN, DESY, RAL, IN2P3. In particolare il gruppo Internet Applications del CERN ha chiesto mandato (HEPix - Apr 99) per lo studio di un sistema Directory a livello HEP e a questo progetto ha dato la sua adesione anche DESY.

Inoltre in ambito commerciale la fusione di Netscape, Sun e AOL portera’ all’integrazione dei sistemi di messaging sviluppati, gia’ fortemente orientati verso il protocollo LDAP.

 

Realizzazione del progetto

 

Il progetto si suddivide in 5 fasi (le prime due sono parallele) che vanno dalla riprogettazione di una struttura dati corrispondente alle esigenze dell’INFN, alla acquisizione delle informazioni necessarie e alla sua realizzazione.

 

Fasi del progetto

  1. Revisione del formato delle entry del DB di RIPE (whois) tuttora esistente ed aggiornamento dei dati: verrą studiato un formato ottimale per le entry del database, che tenga conto dell’integrazione con il sistema di posta e con le mailing lists e di una prossima integrazione con gli attuali sistemi informatici. Condizione essenziale per la realizzazione di questa fase del progetto e’ l’accesso alle informazioni inerenti il personale e la collaborazione dell’Amministrazione Centrale, delle segreterie e dei servizi di calcolo locali, che dovra’ essere formalmente autorizzato nelle opportune sedi. Una volta ottenuta l’autorizzazione a raccogliere i dati, questi dovranno essere forniti in formato ASCII, secondo uno schema che verra’ distribuito (un mese di tempo).
  2. Studio di massima dell’architettura portante del Directory Service, preliminare alla prima fase di test: dislocazione geografica dei server, distribuzione delle informazioni sui vari server (studio del Directory Information Tree: DIT), meccanismi di replica delle informazioni, meccanismi di accesso (privilegi di accesso, possibili interfacce grafiche e non, sicurezza). Un possibile scenario vede la collaborazione del CNAF e della sezione di Milano in una fase preliminare. Verra’ prodotto in questa fase un documento che descrive l’attivita’ svolta e le conclusioni raggiunte. In base alle conclusioni si decidera’ se procedere con le fasi successive. (due mesi di tempo stimati)
  3. Installazione dei server per il test e verifica delle funzionalita’ del sistema e confronto con l’attuale database del personale (whois). Eventuale revisione della fase 2.
  4. Una volta verificate le funzionalita’ e i limiti del DS si valutera’ se e come rendere operativo il servizio a livello nazionale. Questo presuppone la valutazione di un servizio centrale o distribuito. Per le fasi 3 e 4 il tempo stimato e’ di un mese. Verra’ prodotto in questa fase un progetto operativo per la realizzazione del sistema informativo.
  5. In base ai risultati della fase 4, se si valutera’ piu’ opportuno un servizio distribuito, verra’ approntato un pacchetto di installazione del software necessario e la relativa documentazione che verranno resi disponibili in rete. Sarą quindi coordinata l’attivita’ delle sezioni (tempo massimo per l’installazione un mese, per l’inserimento dei dati il termine massimo e’ di un anno).

 

Partecipanti

 

I partecipanti al progetto sono i firmatari del presente documento. Dato l’ampio spettro di applicazioni dei DS e’ necessaria la collaborazione con altri gruppi di lavoro INFN quali mailing e security (ecc.).

 

Manpower

 

Fase 1: per lo studio del formato delle entry e’ necessario l’apporto di tutto il gruppo di lavoro.
  1. FTE allo 0.5%)

Per la raccolta dei dati e’ necessaria la collaborazione dei system manager e delle segreterie locali.

(30 FTE allo 0.5%)

Per il travaso dei dati nel database e’ sufficiente una persona.

(1 FTE al 10% )

La fase 2 prevede la collaborazione dell’intero gruppo di lavoro.

(5FTE al 10%)

Per le fasi 3 e 4 sono necessarie 2 persone al CNAF e 2 a Milano.

(4 FTE al 10%)

La fase 5 richiede la collaborazione di una persona per sezione.

(30 FTE allo 0.5% + 5 FTE al 10%)

Tempi

 

Per la realizzazione dell’intero progetto il tempo massimo stimato e’ di un anno e dipende soprattutto dalla collaborazione esterna necessaria in fase 1 e in fase 5.

 

Requirements

 

Hardware : Per la fase 3 sono necessarie 4 macchine (2 CNAF, 2 Milano) non necessariamente dedicate.
Software : Per la fase 3 e’ sufficiente software freeware (Berkeley Sendmail 8.9.3 o superiore, Berkeley db 2.7.x, openldap 1.2.1)

 

Richieste finanziarie

Non si richiede nessun finanziamento per hardware durante il periodo di test (fasi 1-3), poiche’ si utilizzeranno macchine disponibili nelle sezioni coinvolte (vedi sopra).

In base alle valutazioni effettuate in fase 4), si dovra’ verificare l’eventuale necessita’ di macchine nelle varie sezioni.

Missioni interne 5ML

 

Note

 

La base di dati pubblicata dovra’ ottemperare alle legge 675/96.