Alcune risposte Enrico M.V. Fasanelli Silvia Arezzini, Dael Maselli Riunione comitato di revisione progetto AAI Firenze 21-22 maggio 2008

Domande su PKI & K5 Univocità di username Dati

PKI & K5 Lo scarno riferimento a PKI nel CDR, è realmente dovuto all’aver dato per scontata l’esistenza della INFN-PKI. Paragrafo 2.1.1 Obiettivi: Disegnare la AAI in modo che possa supportare l'autenticazione verso le applicazioni web, centralizzate e non, attraverso certificato X.509.

Slide 21 di Dael

Precisazioni PKI e Kerberos5 dovranno essere i due sistemi di autenticazione supportati. Dovranno essere supportati entrambi, in ogni sede

Username univoci Recepiamo con piacere il suggerimento di andare verso username univoci. Ovviamente tale processo potrà iniziare solo ad INFN-AAI in produzione. Si parte dalla situazione attuale nelle varie sedi e si risolveranno eventuali duplicazioni, se e quando si presenteranno

Dati, privilegi e procedure Dalle domande che abbiamo ricevuto è evidente che non c’è una completa analisi amministrativa: Struttura del dato Procedure di inserimento e modifica Catena delle responsabilità Nel TDR è prevista la definizione delle strutture dei dati e la definizione dei privilegi (Owner, Manager, ecc.). Se ci sarà richiesto di definire anche le procedure, sarà necessario avere supporto amministrativo.

FINE

Dispiegamento della INFN-AAI Enrico M.V. Fasanelli Silvia Arezzini, Dael Maselli Riunione comitato di revisione progetto AAI Firenze 21-22 maggio 2008

Task, Milestone & Co. Precisazioni [dovute] Nella Tabella 2 del CDR, sono stati indicati i vari pezzi che serviranno per INFN-AAI. Per “eccesso di sinteticità” nella stessa tabella sono indicate le Milestones: -Test ed R&D Pilota Produzione 1 - (ha ragione Roberto Cecchini, forse dovevamo chiamarli Tx) 2 - (anche se, lo ammetto, in modo poco esplicito)

Task, Milestone & Co. Precisazioni [dovute]…cont Sempre nella Tabella 2, le uniche indicazioni temporali si riferiscono alle Milestones (e sono calcolate in base al man-power indicato) Solo per le prime due righe la lunghezza delle caselle è indicativa della durata temporale

La famigerata Tabella 2!

Tutti i Task (non proprio minuto per minuto) Riprendendo quanto scritto nel CDR, nelle prossime slides verranno esaminati i vari Task. Per alcuni di essi il livello di approfondimento non potrà che essere di “prima approssimazione”, anche se è già chiaro il tipo di lavoro che sarà necessario svolgere.

M1: LDAP nelle sedi (1) Le 14 sedi che usano LDAP hanno TUTTE una differente configurazione. Dovranno essere verificate, una per una ed in dettaglio. Si dovrà verificare l’assenza di “conflitti” con l’Architettura proposta (disegno del DIT, uso di objectClass, ecc. ecc.) e quindi le possibili soluzioni di integrazione con la INFN-AAI

M1: LDAP nelle sedi (2) Si dovranno verificare, sede per sede, le dipendenze (quali servizi usano LDAP e come) e pianificare le strategie di migrazione alla INFN-AAI L’attività fin qui descritta è strettamente collegata alla scrittura della documentazione tecnica di riferimento per le sedi (M6-fase1), e di disegno tecnico della Directory di INFN-AAI (DIT, objectClass, ecc.)

M1: LDAP nelle sedi (3) Da questa attività dipende poi l’eventuale personalizzazione della GUI di amministrazione della Directory (M5-3) Per ogni sede si prevedono 2.5 settimane di lavoro di una persona INFN-AAI, in collaborazione (almeno per la metà del tempo) con un referente del Servizio di Calcolo e Reti della sede in esame.

M1: LDAP nelle sedi (4) Visto che dal completamento di questo Task dipende il disegno definitivo della Directory, è essenziale che venga eseguito ad alta priorità e con il maggior parallelismo possibile (sulle 14 sedi in questione). 3 FTE dedicati per 3 mesi Visto che nell’economia generale del progetto (che prevede anche tempi “tecnici” come ad esempio per M3-fase1) 3 mesi sono un periodo di tempo ragionevole.

M1: LDAP nelle sedi - Esempio La sezione di Trieste usa LDAP per AA per i servizi di posta elettronica e Web BaseDN: DC=TS, DC=INFN.IT objectClass privata per applicazioni Web Il CNAF usa per il Cento Regionale (Tier1) BaseDN:L=CR, O=INFN, C=IT seeAlso per inserire la lista degli host a cui un utente può accedere in interattivo

M2: Test di scalabilità (1) Gli “-test” hanno dimostrato che l’architettura regge il carico di circa 13 query/sec di tipo RW (anche in condizioni di fortissimo carico effettuato via un loop infinito di query di tipo read) Questi test sono stati effettuati usando macchine virtuali Xen con 2GB di RAM e su una popolazione della Directory circa 4 volte maggiore di quella che ci aspettiamo a regime per la INFN-AAI.

M2: Test di scalabilità (2) Questo risultato ci rende confidenti del fatto che l’architettura reggerà, anche se gli -test sono stati effettuati su un sistema che è 1/3 di quello che si avrà a regime. Sarà quindi necessario estendere i test su una scala maggiore, ed in particolare: Installazione e configurazione di 44 ulteriori server (anche su macchine virtuali) distribuiti nelle varie sedi. Run degli stress-test.

M2: Test di scalabilità (3) Per la semplice installazione e configurazione, essendo gli ambienti offerti dalle varie sedi molto diversi tra loro (distribuzioni Linux diverse) per gli -test sono state necessarie circa 2 ore di lavoro per server (2.4 settimane per 44 server) A questo va aggiunto il lavoro di coordinamento, di supporto e di documentazione, per un totale (stimato) di 4 settimane di una persona INFN-AAI (oltre l’impegno nelle sedi).

M3-fase1: server di core Acquisto, installazione e configurazione dei server di core. Tempi tecnici per l’acquisto: 2-3 mesi

M3-fase2: test su hw finale Per il completamento di questo Task, basterà “trasportare” il sistema di “core” dell’ -test sul nuovo hardware. Non dovrebbero essere necessarie grandi quantità di tempo, ma il Dr. Murphy è sempre in agguato… Una settimana di un FTE è una stima “ragionevole”

M4: test KDC Xen Farm (1) Questo Task dipende dal completamento di M3-fase1, e richiede oltre che l’installazione e configurazione degli slave-KDC sul server che ospiterà la Xen KDC Farm, anche di altrettanti KDC Master, relativi ai vari REALM delle sedi. L’idea operativa è quella di usare due server di una sede “core” come Xen KDC Master Farm, e gli altri due nell’altra sede come Slave Farm.

M4: test KDC Xen Farm (2) I test prevedono sia la verifica della tollerabilità ai malfunzionamenti della propagazione Master->Slave, che la funzionalità della migrazione di macchine Xen tra i server fisici. Nel CDR sono indicate 3 settimane di 3FTE, ma in realtà è un errore. Stimiamo 3 settimane di 1FTE

M5: scrittura software ad hoc E’ necessario scrivere un plug-in che forzi l’uso di un canale TLS in caso di Simple Bind LDAP. Deve essere modificato il plug-in krb5 per automatizzare il popolamento dei KDC. La GUI fornita con FDS è “overkill”. Jxplorer è scritto in Java ed è configurabile via plug-in. Il lavoro dovrà essere terminato entro i primi 4 mesi (abbiamo già in mente i nomi degli sviluppatori)

M6-fase1: Documentazione È sicuramente tra i Task più importanti, ma è di fatto “distribuito” su tutti gli altri. La documentazione è infatti un prodotto previsto di tutti i task, e quindi non c’è l’indicazione di man-power associato a questo Task specifico. Il carico di lavoro relativo alla figura di “responsabile della documentazione” ricade all’interno del tempo-uomo del/dei coordinatore/i del gruppo AAI-WG Esiste comunque una dead-line per la produzione della documentazione tecnica, che corrisponde alla prima Milestone (fine della fase di -test ed R&D)

M7: da protoAAI ad INFN-AAI Dipende da M1,…,M6 e fornisce gli ultimi “input” per l’eventuale completamento di M5 Accordi con DataWeb (unico “cliente” di protoAAI) ci assicurano l’allineamento di protoAAI alla INFN-AAI in termini di schema, ecc. ecc. Questo ci permetterà di passare da protoAAI ad INFN-AAI non solo in modo quasi trasparente per DataWeb, ma in tempi brevissimi (2-3 giorni di lavoro)

M9: Fase pilota Si dovrà “individuare” un congruo (4-6) numero di sedi disponibili ad impiegare man-power locale. Si dovrà verificare tutto, ed in particolare Le procedure di migrazione La documentazione Il tutto va effettuato in 2 mesi solari. Si prevede in questo periodo l’impegno contemporaneo di tutto il gruppo AAI-WG

M10, M11, M12: tutti in(fn) AAI Dando per assunto che la fase pilota si concluda con esito positivo, si può passare ad inserire nella INFN-AAI tutte le altre sedi.

M6-fase2: Documentazione Se non altro per correggere i refusi che troveremo nel corso del tempo…

M8: Windows AD FDS permette la sincronizzazione di username/password con Windows AD Single password e non SSO L’infrastruttura di cross-authenticazion K5 può essere estesa ai domini win.SEDE.infn.it M8 è sganciato dalla prima milestone in quanto AAI-WG ha perduto il contributo fondamentale di esperti Windows.

Formazione Non a caso senza “M”. Si estende oltre l’anno previsto per l’implementazione della INFN-AAI. Formazione “avanzata” per il gruppo di gestione della INFN-AAI Formazione del personale nelle sedi

FINE