Stato: Bozza V, in produzione dal 1/9/2004

I dati EGRID devono essere opportunamente separati in directory per garantire che l'accesso ai dati sia effettuato solo da chi ha le necessarie autorizzazioni. In particolare non vogliamo che gli utenti di un gruppo di ricerca possano, per accidente o malizia, leggere i dati di proprietà di un altro gruppo di ricerca.

Divisione dei dati

Una prima divisione dei dati è in base al contratto sotto il quale sono stati acquistati. Si assume che non ci sia una mappa univoca tra gruppi di ricerca e contratti, ma che ogni gruppo di ricerca possa partecipare a più di un contratto.

Una seconda, e ortogonale, divisione dei dati è in base all'accessibilità dei dati per l'utente finale; dalla riunione del 13/7/2004 e dal colloquio con gli utenti dei gruppi di Roma e Firenze, è emersa la seguente categorizzazione:

Dati originali

i file copiati (senza nessuna alterazione, né del nome, né del contenuto) dal medium di distribuzione (sia esso CD o DVD), e memorizzati nello storage di griglia sotto forma di file .tar.gz .

Dati trasformati

mantengono la stessa informazione presente nei file di RAW Data, rendendola maggiormente fruibile (e.g., binary->ASCII conversion, rinominazione in base al contenuto ed alla naming convention)

Dati di progetto e dati utente

dati disponibili per l'elaborazione finale da parte degli Utenti, con possibile perdita di informazione (e.g., si eliminano campi non utili ai fini di studio). Chiameremo "di progetto" i dati che saranno potenzialmente fruiti da più persone all'interno di uno stesso gruppo, e "di utente" i dati privati di un utente.

Nota Bene: questa divisione sostituisce quella in ISO, GRID e User data, precedentemente elaborata in [EGRID-REQ] .

Si assume che ogni contratto abbia un responsabile (di seguito chiamato "Manager"), che gestisce l'upload dei file di dati originali e ne comanda la trasformazione in ASCII Data, ed è, in ultima analisi, il responsabile dei dati che si trovano sullo SE. La struttura che segue è stata elaborata per fare in modo che il ruolo del manager possa essere effettivamente delegato a un gruppo.

Infine, nella elaborazione dello schema di struttura per le directory, è importante tenere presente le diverse esigenze di backup dei vari tipi di dati.

Scenari di utilizzo

Upload di un file di Dati orginari

Il Manager di un contratto carica sullo SE un CD o DVD coi dati.

Creazione di un file di Dati trasformati

Il Manager di un contratto lancia un programma di trasformazione dei dati da ISO Data a GRID Data.

Creazione di Dati utente

un utente lancia in griglia un programma che crea User Data a partire da GRID Data.

Elaborazione di Dati utente

un utente lancia in griglia un programma che crea altri User Data a partire da User Data.

Riscrittura di Dati originali o trasformati errati

Il Manager deve poter sovrascrivere ISO o GRID data frutto di un errato trasferimento o elaborazione.

Cancellazione di Dati originali o trasformati errati

Il Manager deve poter cancellare ISO o GRID data non più utili o non più disponibili per contratto.

Cancellazione di Dati utente errati

Ogni utente deve poter cancellare i propri files.

Vincoli

Non possiamo usare POSIX ACL [RH-NOACL] . Pertanto, ogni soluzione deve affidarsi solo alla terna di permessi standard UNIX.

Secondo i limiti correnti del kernel Linux, un utente può essere membro di massimo 32 gruppi. Questo limite può essere elevato solo con una ricompilazione del kernel.

Assunzioni

Assumiamo che lo spazio concesso ai dati EGRID risieda tutto su un solo SE. Indichiamo con EGRID/ la directory radice di questo spazio; in pratica EGRID/ è un SURL della forma sfn://SE/flatfiles/SE00/egrid/ .

Assumiamo che sia stato creato un spazio utenti come descritto in [EGRID-RFC-1] , e quindi che:

• ogni utente fisico abbia il suo proprio account;
• ogni account di un utente fisico abbia il suo gruppo privato, ossia un gruppo con lo stesso nome dell'account e che ha come unico membro quell'account [RH-UPG] ;
• esista un gruppo egridusr che raccoglie tutti gli account degli utenti EGRID.

Struttura dell'albero dei dati PFN

Sotto EGRID/ si creano directory fonti, progetti e utenti , per contenere, rispettivamente, dati originali e trasformati, dati di progetto e dati degli utenti.

Dati originali e trasformati

I dati originali e trasformati risiedono nello stesso ramo, chiamato 'EGRID/fonti'; la distinzione tra l'uno o l'altro tipo di dati si fa al secondo livello di diramazione.

Per ogni contratto esistono:

• una directory col nome del contratto al primo livello di diramazione: e.g., per i dati NYSE esiste una directory EGRID/fonti/nyse ;
• un gruppo UNIX che riunisce tutti gli utenti che hanno accesso in lettura ai dati acquistati con quel contratto [EGRID-RFC-1] (utenti fruitori); questo gruppo UNIX ha la proprietà della directory radice di un contratto;
• un gruppo UNIX che riunisce tutti e soli gli utenti che hanno accesso in lettura e scrittura ai dati acquistati con quel contratto [EGRID-RFC-1] (utenti amministrativi); questo gruppo UNIX ha la proprietà di tutte le directory più profonde e dei file relativi ad un contratto.

Il nome della directory che ospita i file acquistati con un certo contratto è deciso dall'amministratore del sistema, di concerto con gli utenti amministrativi del contratto.

Nel resto di questo documento, indichiamo una directory di contratto con ct, indichiamo il gruppo degli utenti amministrativi del contratto ct con ct-rw, indichiamo il gruppo degli utenti fruitori del contratto ct con ct-ro .

Indichiamo di seguito con egridadm l'utente amministrativo del sistema EGRID (account usato dai system manager di EGRID), e con egridusr il gruppo di tutti gli utenti di EGRID.

I permessi sulla directory del contratto ct sono impostati come segue:

proprietario egridadm : rwx

l'utente proprietario (account amministrativo di EGRID) può eseguire tutte le operazioni sui file contenuti nella directory.

gruppo ct-ro : r-x

il gruppo di fruitori del contratto può navigare il ramo di directory che da qui parte.

altri: ---

tutti gli altri non possono navigare l'albero dei file di un certo contratto.

Sotto ogni directory ct di un contratto, esistono due directory originali e trasformati ; i permessi sono impostati su entrambe le directory come segue:

proprietario egridadm : rwx

l'utente proprietario (account amministrativo di EGRID) può eseguire tutte le operazioni sui file contenuti nella directory.

gruppo ct-rw : rwxs

il gruppo amministrativo del contratto può eseguire ogni operazione. Il set-GID bit è necessario per fare in modo che la proprietà dei file che vengono creati dentro la directory rimanga al gruppo associato a quel contratto.

altri r-x

gli "altri" che possono arrivare fin qui sono in realtà gli utenti fruitori ma non amministrativi.

La directory originali contiene un file .tar.gz per ogni medium (CD o DVD) su cui i dati sono distribuiti dal venditore agli utenti che li hanno acquistati. Il nome di questo file deve identificare univocamente il provider dei dati, il periodo a cui i dati si riferiscono, il tipo ("trades", "quotes", "order book"); queste informazioni sono sempre disponibili a chi fa l'upload dei dati. Per i dettagli sulla convenzione di denominazione, cfr. [EGRID-LFNC]

La directory trasformati , parallela a originali , contiene gli stessi dati, ma trattati per risultare in una forma standard, e secondo un albero standard. Quali siano questi standard è ancora oggetto di discussione (14/07/2004). Sembra ragionevole proporre che vi sia una directory per ogni anno di dati, e che dentro questa directory i singoli file abbiano un nome assegnato secondo la "Logical File Name Convention" [EGRID-LFNC] Nota 2/8/2004: Cristian Zoicas ha i dettagli di questi ASCII data.

I singoli file hanno permessi come quelli della directory che li contiene e cioè:

proprietario: rw-

l'utente che ha eseguito l'upload dei dati.

gruppo ct-rw : rw-

il gruppo proprietario del file è il gruppo degli utenti amministrativi, che possono leggere, scrivere e sovrascrivere il file.

altri r--

gli "altri" che possono arrivare fin qui sono in realtà gli utenti fruitori ma non amministrativi.

Osserviamo che con questo schema, occorre che la umask del server GridFTP sia impostata con il valore di default che lascia il permesso di lettura agli "altri". È perciò neccessario che i dati privati di un singolo utente siano protetti in altro modo.

Esempio:

            EGRID/
            |
            |-- fonti/ [ 0755 admin:egrid ]
            |   |
            |   |-- ct/ [ 3750 admin:ct-ro ]
            |   |   |
            |   |   |-- orig/ [ 3775 admin:ct-rw ]
            |   |   |   |-- cd1.tar.gz [ 0664 *:ct-rw ]
            |   |   |   |-- cd2.tar.gz [ 0664 *:ct-rw ]
            |   |   |  ...
            |   |  ...
            |  ...
           ...

                   LEGENDA:  * = utente che ha effettuato l'upload

Dati di progetto

Nel ramo progetti le sottodirectory vengono create dagli utenti; l'utente creatore assume il ruolo di Manager e gestisce la directory creata; il Manager deve avere la possibilità di eliminare la directory con tutto il suo contenuto.

Insieme ad una directory X, assumiamo che venga anche creato un gruppo X i cui membri possono essere scelti dal Manager; il gruppo X ha la proprietà della directory 'X'; il Manager decide se assegnare i permessi di scrittura al gruppo su parti dell'abero X od anche su tutto l'albero.

Per implementare questa politica, i permessi sulla directory progetti sono così assegnati:

rwx owner: egridsgm

la proprietà ad un utente amministrativo, che non coincide con un utente reale; p.es. egridsgm che è l'utente da usare per la gestione del SW, oppure root.

rwx gruppo: egridusr

il gruppo di tutti gli utenti può scrivere in questa directory, per permettere ad un utente arbitrario di creare il suo proprio spazio. In alternativa, si crea un gruppo di utenti abilitati e gli si assegna la proprietà.

---t altri

lo sticky-bit è impostato, in modo che un utente non possa cancellare le directory create dagli altri.

Su ogni directory creata da un utente, i permessi sono inizialmente così impostati:

rwx owner: account dell'utente creatore --

r-xs gruppo: deciso dall'utente creatore

è importante avere il set-GID bit per assicurare che la proprietà di quanto creato in questa directory resti al gruppo; queste directory sono create per la condivisione.

---t altri

lo sticky-bit è impostato, in modo che un utente non possa cancellare le directory create dagli altri, ma solo il Manager (proprietario UNIX della directory) possa cancellare i file di tutti gli altri.

Dovrà probabilmente essere preparato uno script che crei la directory su richiesta dell'utente e imposti correttamente i permessi. Nota bene: 2/8/2004 per la mancanza di un client GridFTP in grado di eseguire le operazioni CHMOD e CHGRP, l'implementazione di questa feature è rimandata; le directory dei progetti verranno create "off-grid" da uno script che gira direttamente come cron job sugli SE, e non come lavoro di griglia. Nota bene: 24/9/2004 Il client UberFTP è in grado di eseguire le operazioni richieste; "Angelo Leto":mailto:aleto@ictp.trieste.it si occupa di scrivere lo script appropriato.

Inoltre, questo schema suggerisce una iniziale interazione tra le directory progetti/X e le sotto-VO create all'interno della VO EGRID: deve essere previsto uno script che permetta ad ogni utente di creare la sua sotto-VO ed il gruppo UNIX corrispondente, di aggiungere e togliere utenti all'uno ed all'altra contemporaneamente. Nota 2/8/2004: anche questo codice non è stato ancora scritto.

Dati utente

Sotto la directory EGRID/utenti/, ci sarà una directory per ogni utente. Dentro la directory EGRID/utenti/X appartenente all'utente X , è anche creata una sottodirectory EGRID/utenti/X/private per comodità dell'utente.

Variante: è utile raggruppare ulteriormente gli spazi utente in base all'appartenenza ad un determinato gruppo di ricerca?

La directory di un utente ha proprietà come segue:

proprietario: utente --

gruppo: gruppo privato dell'utente

questo, e il bit set-GID sulle directory comuni, permette agli utenti di tenere costantemente una umask 002 senza preoccuparsi di dove si va a creare un file.

I permessi sono come segue:

proprietario: rwx

gruppo rwx

gruppo privato dell'utente

altri: r-x

lo spazio di un utente è navigabile dagli altri; si può pensare di restringere questi permessi a --x , in modo che la directory resti navigabile ma non sia listabile.

Nella directory personale di ogni utente, ci sarà una sottodirectory private/ con i seguenti permessi:

proprietario: rwx

il proprietario è ovviamente l'utente stesso

gruppo: rwx

gruppo privato dell'utente

altri: ---

gli altri non devono assolutamente poter leggere in questa directory! Nota bene 24/9/2004 anche questa terna di permessi si discosta dalla normale umask del server GridFTP, quindi la creazione delle home degli utenti avviene "off-grid" per mezzo di un cron job che crea le home di tutti gli utenti definiti nel server LDAP di EGRID.

Con questo schema, l'utente può creare sottodirectory nella sua directory, per condividere file con altri di ogni gruppo di cui è membro: p. es., l'utente X membro del gruppo nyse crea una directory EGRID/utenti/X/nyse e assegna la proprietà di gruppo al gruppo nyse. Poiché EGRID/utenti/X è navigabile dagli altri, gli utenti del gruppo nyse potranno raggiungere utenti/X/nyse e vedere i file lì contenuti. Nota 2/8/2004: questo non si può fare finché non avremo un client GridFTP in grado di fare CHMOD e CHGRP.

Software

Lo script egrid-mkdirhier permette di creare l'intera gerarchia delle directory qui sopra descritta con una semplice invocazione del comando. La documentazione del software è distribuita assieme allo script stesso.

Riferimenti

[EGRID-REQ] EGRID Project Development Process

[EGRID-RFC-1] Sistema di utenti per realizzare l'accesso separato ai dati

[EGRID-LFNC] Logical File Naming Convention

[RH-NOACL] RH7.2 Kernel 2.4.20 ChangeLog

[RH-UPG] Users, Groups and User-Private Groups

Modifiche

$Log: 2.txt,v $ Revision 1.5 2004/09/24 10:17:43 rmurri

• Aggiornati i nomi delle directory, per corrispondere a quelli effettivamente creati dagli script di produzione.
• Traduzione di tutti i nomi in italiano.

Revision 1.4 2004/09/06 15:55:53 rmurri

• link a egrid-mkdirhier

Revision 1.3 2004/09/06 15:36:33 rmurri

• cambiati i nomi delle directory di struttura