Toasted Tech Blog

C’era molta gente, sabato 27 alla giornata del Linux Day, tenutasi al dipartimento di fisica a Perugia. Il linux day, è una amnifestazione (se così si può dire) orientata alla conoscenza di Linux e del mondo open-source in generale, tenuto da personale qualificato e non, che mette a disposizione degli utenti, le proprie conoscenze su un argomento.

Il linux day era composto da tre sezioni:

• Scuola / Accessibilità
• Divulgativo / Home
• Tecnico / Professional

la prima sezione era rivolto prevalentemente ad alunni e docenti di scuola superiore, con l’obiettivo di introdurre argomenti relativi al software libero e ad alcune panoramiche sull’implementazione e la gestione di un laboratorio con strumeti avanzati di informatica, sul linguaggio Python e sul software piratato.

La seconda sezione riguardava la distribuzione Ubuntu, i cicli di vita del software e un po’ di storia della crittografia. Tutto comunque, rivolto a persone che vogliono avvicinarsi a Linux, e magari hanno un po’ di comprensibile paura nell’utilizzare uno strumento nuovo di lavoro, considerato che fino a questo momento il buon vecchio Windows, tra alti e bassi, ha fatto sempre il suo lavoro.

La terza sezione era indicata a persone che utilizzano Linux, e magari vogliono ampliare la propria conoscenza sul sistema operativo, e le implementazioni che mette a disposizione, come LDAP (Lightweight Directory Access Protocol) protocollo standard per l’interrogazione e la modifica dei servizi di directory, o XEN.

Avendo partecipato all’ultima sezione, vi espongo ciò che per me è risultato molto interessante.

In primo luogo, l’esposizione del nostro collega ed amico Simone Pascarosa, inerente a LDAP + VLAN + XEN è stata molto interessante, anche perché comunque riguarda una delle tematiche che affrontiamo su ogni sistema operativo, come la messa in rete della macchina l’installazione di software per la virtualizzazione oppure la semplice costruzione di una rete domestica, molto facile a vista d’occhio, ma con delle caratteristiche interessanti.

Il protocollo LDAP (sopra è riportato l’acronimo), è stato introdotto alcuni decenni fa, quando negli anni settanta si sentì la necessità di sviluppare nuove tecnologie di comunicazione, i moti sistemi ideati erano differenti tra loro e quindi incompatibili, perciò serviva uno standard che permettesse di far cooperare questi dispositivi.

In principio, fu introdotto l’ OSI Reference Model (ISO 7498), che individuò sette strati nella comunicazione di dati con il trasporto fisico al livello più basso, e i protocolli dell’applicazione ai livelli più alti. Gli altri standard si svilupparono insieme con Internet e con la ricerca portata avanti dalla DARPA negli USA.

Un’area importante era quella dei servizi di directory. Il CCITT creò lo standard X.500 nel 1988, che divenne ISO 9594 Data Communications Network Directory Recommendations X.500-X.521 nel 1990.

Secondo questo standard, la comunicazione tra directory client e server usa il directory access protocol (DAP). Ma per essere operativo, il DAP richiede l’intera pila OSI, poiché è un protocollo del livello applicazioni.

LDAP

Si voleva però un’interfaccia ad una directory server X.500 che usasse meno risorse o un protocollo leggero. Per questo motivo venne sviluppato LDAP, come alternativa snella al DAP. LDAP richiede il più leggero e popolare protocollo TCP/IP invece della pila OSI. Inoltre LDAP semplifica certe operazioni di X.500 e omette certi aspetti intricati.

Due precursori di LDAP sono rappresentati dagli RFC rilasciati da IETF, Directory Assistance Service (RFC 1202) e DIXIE Protocol Specification (RFC 1249). Sono entrambi RFC informativi e non vennero proposti come standard. Il directory assistance service (DAS) definì un metodo per il quale un directory client può comunicare con un proxy su un host OSI che rilasciava richieste X.500 a nome del client. DIXIE è simile a DAS, ma offre una conversione più diretta del DAP. La prima versione di LDAP venne definita in X.500 Lightweight Access Protocol (RFC 1487), sostituito da Lightweight Directory Access Protocol (RFC 1777).

Recentemente, il bisogno di unire le operazioni LDAP con XML nell’uso dei Web Services ha dato alla luce un nuovo linguaggio chiamato Directory Services Markup Language (DSML). La più recente versione è DSMLv2. DSML è un generico formato per importare/esportare tali informazioni. In DSML i dati della directory possono essere condivisi tra applicazioni che supportano tale formato senza esporre il protocollo 17 LDAP. XML offre un metodo effettivo per presentare e trasferire i dati; i servizi di directory permettono di condividere e gestire i dati e sono così un prerequisito necessario per effettuare operazioni online. DSML è progettato per rendere il servizio di directory più dinamico impiegando XML. DSML è uno schema in XML per lavorare con le directory, ed è definito con un Document Content Description (DCD). Così DSML permette ai programmatori di XML di accedere alle directory LDAP senza avere a che fare con l’interfaccia LDAP o API per l’accesso alle directory, offrendo un modo consistente per lavorare con directory multiple e differenti.

Directory LDAP

Il termine di uso comune “directory LDAP” può essere fuorviante. Nessun tipo specifico di directory è una “directory LDAP“. Si potrebbe ragionevolmente usare il termine per descrivere qualsiasi directory accessibile tramite LDAP e che possa identificare gli oggetti contenuti tramite nomi X.500, ma Directory come OpenLDAP e i suoi predecessori sviluppati presso l’Università del Michigan, anche se progettati espressamente per l’accesso tramite LDAP piuttosto che come ponte verso X.500, come avveniva per i prodotti forniti da ISODE, non sono directory LDAP più di qualsiasi altra directory accessibile tramite protocollo LDAP.

Struttura

L’informazione all’interno di una directory è organizzata in elementi chiamati entry.

Gli elementi di una directory LDAP presentano una struttura gerarchica che riflette confini politici, geografici o organizzativi. Nel modello X.500 originale, gli elementi che rappresentano gli stati appaiono in cima all’albero, con sotto di essi gli elementi per gli stati federali o le organizzazioni nazionali (normalmente nelle installazioni di LDAP vengono usati i nomi del DNS per strutturare i livelli più alti della gerarchia). Più in basso potrebbero apparire elementi per rappresentare le divisioni all’interno di una singola organizzazione, singole persone, documenti, stampanti o qualsiasi altra cosa.

Nella struttura ad albero, ad ogni livello esiste un Relative distinguished name (RDN) che lo identifica (ad esempio ou=persona). L’unione di tutti i RDN, presi in successione dal nodo foglia fino alla radice, costituisce il distinguished name (DN), una stringa che rappresenta univocamente una entry nella directory. Un dn può essere ad esempio:

"cn=System Doe,ou=persona,dc=wordpress,dc=com"

Ciascuna entry ha una serie di attributi, costituiti dall’associazione attributo-valore; per ogni attributo possono esserci più valori. Ognuno degli attributi dell’elemento è definito come membro di una classe di oggetti, raggruppati in uno schema. Ogni elemento nella directory è associato a una o più classi di oggetti, che definiscono se un attributo sia opzionale o meno, e che tipo di informazioni questo contenga. I nomi degli attributi solitamente sono scelti per essere facilmente memorizzabili, per esempio “cn” per common name(semplicemente nome comune), o “mail” per un indirizzo e-mail. I valori degli attributi dipendono dal tipo, e la maggioranza dei valori non binari sono memorizzati in LDAPv3 (LDAP versione 3) come stringhe UTF-8. Per esempio, un attributo di tipo mail potrebbe contenere il valore “user@example.com”, mentre un attributo “jpegPhoto” potrebbe contenere una fotografia nel formato (binario) JPEG.