E. Ferro, LNF Febbraio 2005 Release INFN-GRID, apt+kickstart server, yaim, quattor Enrico Ferro INFN - Padova

E. Ferro, LNF Febbraio 2005 Contenuto ❖ Release INFN-GRID ❖ Apt + kickstart server ❖ Yaim: lcg-yaim e ig-yaim ❖ Quattor (solo qualche cenno)

E. Ferro, LNF Febbraio 2005 ¡ ATTENZIONE ! ❖ Prima di cominciare mettiamo in chiaro: –YAIM = set di scripts bash per l'installazione e la configurazione del middleware –YAM = tool per il mirroring di repositories apt –YUM = tool simile ad apt per semplificare l'installazione e l'aggiornamento di packages (non ci interessa) ❖ Quindi: –Configurare middleware = YAIM –Mirrorare repositories apt = YAM –Simile ad apt ma non ci interessa = YUM

E. Ferro, LNF Febbraio 2005 ReleaseINFN-GRID

Perché esiste una release INFN-GRID ❖ "Anticamente" per ovviare a imperfezioni “croniche” cui ogni site manager doveva porre rimedio (Datagrid) ❖ Aggiungere VO "nazionali" ❖ Partecipazione ad altri progetti (FIRB), ingresso di nuove VO/esperimenti INFN => requisiti da altri ambiti applicativi non previsti in LCG ❖ Integrazione nuovo middleware (e.g. VOMS) ❖ Configurazione diversa (e.g. monitoraggio GridICE abilitato sui WN) ❖ Attualmente e' basata sulla release di LCG (ma in futuro sara' quella di EGEE)

E. Ferro, LNF Febbraio 2005 Personalizzazioni INFN-GRID ❖ Aggiunta di numerose VO (circa 12) ❖ Autorizzazione via VOMS + LCAS/LCMAPS per alcune VO (ne saprete di più oggi pomeriggio) ❖ Configurazione SSH per copia tra WN senza password (trucco per jobs MPI senza sharing home directories) ❖ Coda cert solo per jobs di test/certificazione (solo VO infngrid e dteam) ❖ Abilitazione Gridice per il monitoraggio dei singoli WN ❖ AFS sui WN ❖ Configurazione WN su rete privata (*) ❖ Documentazione su configurazione LSF (*)

E. Ferro, LNF Febbraio 2005 Architetture HW ❖ IA32 ❖ IA64 in fase di messa a punto da LCG (gia' ok per i WN ma non ancora disponibile)

E. Ferro, LNF Febbraio 2005 Prossima release: LCFG & RH73 ❖ LCG per ora continua a supportare anche RH73 su LCFG ❖ Su INFN-GRID transizione su Scientific Linux CERN (=RHEL ricompilata da Fermilab + CERN) ❖ Non esiste né ci sarà mai supporto per LCFG su SL ❖ Il gruppo “install” si e' occupato di preparare la strada al deployment. Sono stati analizzati: –Quattor: “discendente svizzero dello scozzese LCFG” –yaim: “pragmatico set di script bash per l'installazione e configurazione middleware” ❖ Conclusioni (per ora): –Prematuro l'utilizzo di quattor, non e' supportato “direttamente e ufficialmente” da LCG –Solo Tier1 lo usa => per ora non è la soluzione universale –Si è preferito l'approccio “minimalista” di yaim

E. Ferro, LNF Febbraio 2005 apt+kickstart server

E. Ferro, LNF Febbraio 2005 Prima del middleware... ❖ Vedremo in seguito come funzionano i nuovi tools per configurare il middleware... ma ora senza LCFG, come installare SL su tutti i WorkerNodes? ❖ Il gruppo install ha documentato (*) il setup di un server destinato a: –Installare il sistema operativo via kickstart –Mantenere una replica locale dei repository apt di os, updates, middleware ❖ yaim utilizza tale server per l'installazione dei packages `(*) Presto sara' disponibile il documento

E. Ferro, LNF Febbraio 2005 apt+kickstart server ❖ Caldamente consigliata installazione su SL: –no “riciclaggio” di server LCFG o macchina con RH73 senza preventiva reinstallazione con SL! ❖ Permette installazione con kickstart via PXE con la triade: –DHCP server –TFTP server –HTTP server ❖ Mantiene mirror dei repositories APT mediante yam: –Sistema operativo + updates –Middleware LCG, certificati CA –Middleware INFN-GRID ❖ E' stato messo a punto dal gruppo 'install' –Torino: F. Nebiolo, R. Brunetti; Roma1: M. Serra, A. Barchiesi; Padova: C. Aiftimiei; CNAF: L. Carota; Roma2: C. Dalle Fratte

E. Ferro, LNF Febbraio 2005 Yam ❖ Tool per gestione repositories apt: –Mantiene una replica locale di repositories apt esterni (ftp, http, rsync, etc...) –Crea nuovi repositories per esigenze locali ❖ Una volta mirrorati, i repositories sono resi disponibili localmente via HTTP ❖ Yam opera su due diversi alberi di directories opportunamente organizzati: –Albero “srcdir”: contiene gli rpm scaricati da altri repositories –Albero “wwwdir”: contiene metadati apt + symlinks agli rpm in srcdir. Mantenuto da yam, e' accessibile via HTTP ❖ Possono essere aggiunti repositories locali ❖ Per semplificare il deployment usare ig-yam (non usate yam “liscio”)

E. Ferro, LNF Febbraio 2005 Yam: /etc/yam.conf (solo un esempio) [main] # ROOT DEI REPOSITORIES (qui ci sono gli rpm) srcdir = /var/rep # ROOT DEI REPOSITORIES VIA WEB (qui symlinks agli rpm + metadati apt) wwwdir = /var/www/html/rep... # REPOSITORIES APT DEL SISTEMA OPERATIVO DA REPLICARE [slc303] name = Scientific Linux CERN (i386) arch = i386 os = updates = myrpms = file:///opt/i_miei_rpms/... # REPOSITORIES APT DEL MIDDLEWARE LCG DA REPLICARE – 1 REP. x RELEASE! [lcg_sl3] name = LCG middleware (i386) arch = i386 2_3_0 = # REPOSITORIES APT DEL MIDDLEWARE INFNGRID DA REPLICARE – 1 REP. x RELEASE! [ig_sl3] name = INFN-GRID middleware (i386) arch = i386 2_3_0 =

E. Ferro, LNF Febbraio 2005 Yam: utilizzo ❖ Puo' essere eseguito a linea di comando: –yam -uvv: download solo i repositories OS + updates –yam -xvv: download tutti gli altri repositories –yam -gvv: crea metadati per apt + tutti i symlinks per pubblicare i pacchetti via HTTP ❖ Tutto in un colpo solo –yam -guxvv: tutto in un colpo solo ❖ 'vv' = verbose ❖ Ovviamente nulla vieta di farlo eseguire da cron per essere sincronizzati con gli updates

E. Ferro, LNF Febbraio 2005 Riassumendo: apt+kickstart server ❖ E' un server con cui installare il sistema operativo –Contiene tutta la distribuzione –Kickstart file di esempio –Pxelinux.cfg di esempio –Tools per la selezione dei nodi da installare (ig-bootselect) –Meccanismo di ack via CGI per segnalare la fine dell'installazione ❖ Un mirror di repositories apt –Yam scarica rpm + crea metadati. In caso di installazione/upgrade: si aggiorna /etc/yam.conf si esegue yam -guxvv (scarica rpm + crea repository apt) ❖ L'installazione dei packages e la configurazione sara' operato da yaim

E. Ferro, LNF Febbraio 2005 yaim

yaim ❖ Approccio minimalista: “middleware e basta”, quindi: –Non installa il sistema operativo –Non ha meccanismi di aggiornamento automatici tipo LCFG –Va eseguito a mano su ogni nodo ❖ E' un insieme di scripts per: –Installazione degli RPM del middleware –Configurazione del middleware ❖ 100% bash ❖ Utilizza apt per installare i packages (stesso approccio di INGRID) ❖ Ha 1 file di configurazione molto simile a site-cfg.h ❖ Modulare

E. Ferro, LNF Febbraio 2005 Piccola parentesi: tentakel + ssh pubkey ❖ Prima di addentrarci in yaim, e' bene ribadire: –Non ci sono piu' meccanismi automatizzati in stile LCFG –Gran parte dei comandi descritti nelle prossime slides vanno eseguiti a mano su ogni nodo ❖ Suggerimenti del gruppo install: –Tentakel (shell distribuita) –Ssh con autenticazione via public key ❖ Torniamo a yaim...

E. Ferro, LNF Febbraio 2005 Personalizzazioni INFN-GRID: ig-yaim ❖ Attenzione: –Il package lcg-yaim è rilasciato da LCG e contiene scripts per configurare il middleware LCG –ig-yaim contiene quanto serve per attuare le personalizzazioni INFN-GRID viste in precedenza ❖ In pratica ig-yaim è un set di wrappers per lcg-yaim –Vanno installati entrambi –Gli script di ig-yaim “completano” quelli di lcg-yaim (i quali fanno il 98% del lavoro) –Un po' come in OOP, ig-yaim "eredita quasi tutto da lcg-yaim, ridefinisce qualcosa e aggiunge qualcos'altro”

E. Ferro, LNF Febbraio 2005 Utilizzo di yaim (1/5) 1. installazione sistema operativo ❖ Il primo passo e' ovviamente installare il sistema operativo ❖ Si puo' seguire la “ricetta” del server apt+kickstart ma non e' obbligatorio

E. Ferro, LNF Febbraio 2005 Utilizzo di yaim (2/5) 2. installazione di lcg-yaim e ig-yaim su tutti i nodi ❖ lcg-yaim (fornito da LCG) effettua la quasi totalità delle operazioni di configurazione "standard"; ❖ ig-yaim (fornito dal gruppo Release di INFN-GRID) contiene le personalizzazioni di INFN-GRID

E. Ferro, LNF Febbraio 2005 Utilizzo di yaim (3/5) 3. Si compila una copia ig-site-info.def: ❖ Molto simile a site-cfg.h di LCFG, una serie di coppie nome- valore da definire (e.g. hostname, quali VO sono supportate, etc...) ❖ Naturalmente ig-site-info.def (ig-yaim) è la versione INFN- GRID di site-info.def (lcg-yaim) e conterra' qualche opzione in piu'

E. Ferro, LNF Febbraio 2005 Utilizzo di yaim (4/5) 4. Si installano i packages con ig-install_node. Esempio: ig-install_node ❖ Lo script ig-install_node: –1. configura apt così che acceda ai repositories del middleware LCG e INFN-GRID –2. Installa il metapackage con apt: E' un rpm “fittizio”: non contiene alcun file ma per essere installato richiede tutti packages necessari per un particolare gridelement Esistono metapackages per CE, SE, etc... ❖...quindi installare 1 metapackage implica far installare ad apt tutti i packages di un grid element! ❖ ig-install_node e' un wrapper di install_node

E. Ferro, LNF Febbraio 2005 Utilizzo di yaim (5/5) 5. Configurazione middleware con config_tiponodo. Es.: config_ig_CE_torque ❖ Esiste un config_tiponodo per ogni grid element ❖ config_tiponodo esegue una sequenza di funzioni bash specializzate: –config_globus, config_lcas,... ❖ Tali funzioni, simili ai componenti di LCFG: –sono racchiuse ognuna in 1 file (1 funzione = 1 file) –sono riutilizzate in più config_tiponodo –specializzate (1 solo aspetto limitato) –idempotenti

E. Ferro, LNF Febbraio 2005 Riassunto transizione a SL + yaim ❖ Installazione apt+kickstart server (una tantum) ❖ Su apt+kickstart server, download middleware –Aggiornamento /etc/yam.conf (1 release = 1 repository) –yam -guxvv ❖ Compilazione ig-site-info.def ❖ Su ogni nodo: –installazione lcg-yaim e ig-yaim –Installazione middleware con ig-install_node –Configurazione middleware con config_CE_torque –Configurazione manuale q.b.

E. Ferro, LNF Febbraio 2005 Quattor: qualche cenno

E. Ferro, LNF Febbraio 2005 Quattor, storia e filosofia ❖ EDG (2001): LCFG era solo una soluzione provvisoria per pochi mesi (!) destinato ad essere rimpiazzato: –Ma quattor alla fine del progetto era ancora un prototipo –CERN + Università di Madrid hanno continuato lo sviluppo ❖ Sostanzialmente identico ad LCFG per filosofia e architettura ma completamente riscritto –Server mantiene configurazione “desiderata” dei nodi distribuita poi come XML (“mkxprof”) –Sui nodi un demone sincronizza la configurazione in uso con quella desiderata (“rdxprof”) –Modifiche attuate da una serie di componenti (“componenti di LCFG”) ❖

E. Ferro, LNF Febbraio 2005 Quattor, pro e contro ❖ Pro –Più affidabile di LCFG –Meno legato al sistema operativo di LCFG (e.g. Solaris) –Linguaggio più potente per la definizione delle configurazioni –Pensato “in grande” (flessibilità, scalabilità) –Sarà supportato da EGEE ❖ Contro –Numero files di configurazione O(100) –Complessita' del linguaggio (ci vuole tempo per prendere pratica) –Complessita' del sistema di gestione dei repositories di packages –E' supportato su base volontaria (in uso al CERN, CNAF, NIKHEF (?), LAL (?)) ma non esiste supporto diretto da LCG

E. Ferro, LNF Febbraio 2005 Dopo la rinomata mensa di Frascati... ❖ Nel pomeriggio –Daremo un'occhiata a un server apt+kickstart installato –Non vedremo niente di yaim