Questa è la pagina dell'utente Sarkiaponius.

Se la trovate utile, tornate. Siete i benvenuti.

Plone

Per quanto questo prodotto sia piuttosto solido e maturo, presenta ancora problemi di compatibilità con MS Office che limitano la sua effettiva usabilità a situazioni del tutto irrealistiche in cui non sia necessario lo scambio di file in formato MS Office di una certa complessità.

In questa sezione ho raccolto varie esperienze negative relative a problemi di compatibilità, a cui ho potuto trovare una soluzione dignitosa.

Lo strumento di base per inserire immagini in Writer è la voce di menù Insert/Graphics/From Fil. L'immagine viene inserita in una posizione che dipende dalla posizione del cursore in un modo che può essere regolato in seguito dalle voci Anchor, Wrap e Alignment del menù dell'immagine (presentato right-click sull'immagine dopo averla selezionata con un left-click).

A questo punto l'immagine è ridimensionata quasi certamente in modo inadeguato, e occorre assegnarle le dimensioni volute agendo sulle voci Graphics/Type e Graphics/Crop del menù dell'immagine. In entrambe le voci è presente una check-box del tipo Keep ratio o Keep scale, ma non sembrano avere alcun effetto: ci si aspetterebbe infatti che, regolando ad esempio la larghezza dell'immagine, l'altezza sia regolata di conseguenza in modo da conservare il rapporto fra le due, ma questo non avviene. Diventa piuttosto scomodo regolare i due parametri, in questo modo. In particolare, se l'immagine deve essere portata alla larghezza della pagina, viene spostaneo marcare la check-box Keep ratio nella voce Graphics/Type, e poi portare la larghezza al 100%, ma l'altezza rimane invariata, e quindi l'immagine finale appare fortemente schiacciata.

Anche il bottone Original size nella stessa voce ha effetti sconcertanti: invariabilmente porta l'immagine a dimensioni che nulla sembrano avere a che fare con le dimensioni originali dell'immagine.

Esportando in formato Word 2000 un file contenente immagini inserite nel modo sopra descritto, si ottiene effettivamente un file che Word sembra mostrare allo stesso modo di Writer. Normalmente, però, le immagini sono accompagnate da didascalie, e Writer le inserisce in modo diverso da quanto fa Word, con il risultato che Word non riesce a tenerle allineate.

Writer inserisce la didascalia di un'immagine tramite la voce Caption del menù dell'immagine. Il risultato è la creazione di un frame che avvolge l'immagine e la didascalia, e che sembra mettere in difficoltà il filtro di esportazione in formato Word. Per ovviare a questo inconveniente si può inserire il testo della didascalia semplicemente al di sotto dell'immagine, senza creare alcun legame fra l'immagine e il testo come oggetti. L'eventuale spostamento delle due entità dovrà dunque avvenire sempre selezionandole entrambe.

Questa sezione raccoglie spunti relativi all'uso del noto editor di testo Emacs, non immediatamente ricavabili dalla pur vastissima documentazione disponibile.

La forma speciale defun è usata in EmacsLisp per definire una nuova funzione. La sintassi generale è:

 (defun NAME ARGLIST [DOCSTRING] BODY...)

Gli elementi in maiuscolo hanno il seguente significato:

NAME

è il nome con cui invocare la funzione

ARGLIST

una lista, eventualmente vuota, di argomenti della funzione

DOCSTRING

documentazione opzionale della funzione

BODY

corpo della funzione, inteso come codice Listp valido.

Ad esempio, il seguente codice definisce una funzione che inserisce nel testo la data odierna in formato YYYY-MM-DD:

 (
   defun insert-date () 
   (format-time-string "%Y-%m-%d" (current-time))
 )

È possibile eseguire una funzione senza digitarne il nome assegnandole una sequenza di tasti con la funzione global-set-key, la cui sintassi generale è:

 (global-set-key KEY COMMAND)

Gli elementi in maiuscolo hanno il seguente significato:

KEY

una sequenza di tasti valida

COMMAND

un comando valido.

Se COMMAND è un comando predefinito di Emacs, dev'essere del tipo 'nome-comando. Se si tratta di una funzione definita dall'utente, deve allora essere del tipo (nome-funzione). Questa è infatti la tipica sintassi Lisp per l'esecuzione di una funzione.

Ad esempio, se insert-date è definita come sopra, l'esecuzione della seguente espressione fa sì che, durante la sessione corrente di Emacs, indipendentemente dal modo, inserisce la data corrente al posto del cursore quando si digita la sequenza C-x C-b

 (global-set-key "\C-x\C-d" (insert-date))

Definire le funzioni come sopra in alcuni casi non è sufficiente. La funzione insert-date, come definita sopra, svolge egregiamente il suo compito, ma si provi ad invocare ripetutamente una funzione leggermente diversa come la seguente:

 (
   defun insert-time () 
   (format-time-string "%H:%M:%S" (current-time))
 )

Verrà mostrato sempre lo stesso valore, quello corrispondente all'ora in cui la funzione è stata definita. Infatti la forma speciale defun è a sua volta una funzione, invocata per definire una nuova. Essa quindi userà il valore di current-time nel momento in cui viene invocata, e così la funzione sopra riporta sempre lo stesso valore costante.

Occorre fare in modo che la funzione insert-time provochi sempre una nuova invocazione di current-time. A tal fine si usa la forma speciale interactive. Il suo uso può essere alquanto sofisticato, ma in questo caso basta dire che essa fa in modo che una funzione diventi un comando, che può essere invocato interattivamente provocando tutte le invocazioni eventualmente necessarie. La funzione insert-time va così modificata:

(defun insert-time ()
  (interactive)
  (
    princ
    (
      format-time-string "%H:%M:%S" (current-time)
    )
    (current-buffer)
  )
)

Come si vede, la forma speciale interactive è invocata all'inizio del corpo della nuova funzione, senza argomenti. Per mostrare il valore della funzione nella posizione del point nel buffer corrente è ora necessario invocare la funzione di output princ. In mancanza di questa funzione, il valore di insert-time non sarebbe mai visualizzato. Il secondo argomento di princ specifica il buffer destinazione, ma può indicare anche altre destinazioni, compresa l'usuale area di eco di Emacs.

Esistono fondamentalmente due programmi per creare e copiare CD in Linux: cdrecord e cdrdao. Sotto molti aspetti sono del tutto equivalenti, ma il secondo è più indicato nell'incisione di CD audio a partire da traccie distinte, in quanto è possibile controllare, e soprattutto sopprimere, la pausa di due secondi tipicamente inserita fra una traccia e l'altra, e che sarebbe fastidiosa se le singole traccie sfumassero l'una nell'altra (come avviene nelle registrazioni di concerti dal vivo).

Entrambi i comandi hanno un'interfaccia a riga di comando, ma sono disponibili numerosi applicativi grafici che, secondo la classica filosofia UNIX, si limitano ad utilizzare questi due programmi, in maniera pressocché trasparente per l'utente. Fra questi, xcdroast, gcombust, gnome-toaster e molti altri.

Nelle prossime sezioni saranno illustrate alcune applicazioni elementari di cdrecord. Le stesse operazioni dovrebbero essere possibili con cdrdao, sia pure con le dovute differenze di sintassi.

Sia cdrecord che cdrdao sono stati sviluppati per accedere esclusivamente ai dispositivi con interfaccia SCSI, solitamente molto affidabili, ma anche costosi, e quindi raramente installati su sistemi personali.

Linux consente di emulare l'interfaccia SCSI al di sopra dell'interfaccia IDE o EIDE, normalmente utilizzata per accedere a vari tipi di unità a disco sui sistemi personali. Grazie a questa emulazione, è possibile usare cdrecord e cdrdao anche sui sistemi personali, come se fossero muniti di dispositivi SCSI.

Per indivuare i dispositivi, lo standard SCSI utilizza tre numeri separati da virgola, come all'inizio della riga seguente:

2,0,0   200) 'HL-DT-ST' 'RW/DVD GCC-4521B' '1.04' Removable CD-ROM

estratta dall'output del comando cdrecord -scanbus oppure cdrdao scanbus.

Versioni recenti di cdrecord consentono di identificare i dispositivi secondo l'uso prevalente in GNU/Linux, cioè nella forma /dev/sgN, usata per riferirsi a dispositivi a carattere con interfaccia SCSI nativa o emulata. L'effettivo valore per il numero N dipende dalle situazioni, ma in un sistema con unico dispositivo per lettura e incisione questo viene di solito identificato con /dev/sg0.

È utile ricordare che, in GNU/Linux, lo stesso dispositivo fisico può essere di norma considerato un dispositivo a carattere oppure un dispositivo a blocchi. La differenza è evidenziata dal nome: le notazioni /dev/sg0 e /dev/scd0, ad esempio, identificano lo stesso dispositivo, ma la prima presuppone un accesso per caratteri, la seconda un accesso per blocchi.

Nota. L'autore di cdrecord sottolinea che il driver Linux sg, che consente di indicare un dispositivo con un nome del tipo /dev/sgN, è caratterizzato da un pessimo disegno generale. Egli stesso, però, raccomanda di provare prima questo tipo di accesso.

Se non si usa la notazione SCSI, si dovrà quindi fare attenzione a identificare il dispositivo con il nome opportuno. Recenti versioni di cdrecord accettano anche nomi come /dev/hdc o /dev/hdd, normalmente usati per accedere a dispositivi con interfaccia IDE. Per maggiore portabilità e compatibilità è comunque consigliabile usare sempre la notazione SCSI.

Alcune distribuzioni, fra cui Fedora Core, hanno introdotto versioni di cdrecord e cdrdao fortemente orientate all'interfaccia IDE, e che quindi riconoscono anche nomi del tipo /dev/hdc o /dev/hdd, tipici dei dispositivi IDE. Nello stesso tempo, queste distribuzioni hanno rimosso il supporto per l'emulazione SCSI dei dispositivi IDE. Questo semplifica l'utilizzo agli utenti poco esperti di SCSI, ma sembra aver introdotto qualche problema, per cui, se si riscontrano comportamenti sospetti, è meglio ripristinare l'emulazione SCSI.

Normalmente ci si trova ad operare con CD monosessione, cioè CD a cui non è possibile aggiungere dati dopo la prima incisione. Infatti, alla fine di un'incisione, il Cd viene normalmente fissato (dall'inglese to fixate), nel senso che vengono registrate le informazioni necessarie a rendere leggibile il CD.

In alcuni casi si rivela però molto utile poter aggiungere dati ad un CD, sia esso un CD-R o un CD-RW, potendo nello stesso tempo accedere al contenuto del CD come se fosse un normale CD monosessione. A questo scopo lo standard ISO9660 prevede la possibilità di creare CD multisessione: quando il CD viene fissato alla fine di una sessione, vengono registrate informazioni supplementari che consentono di aggiungere nuovi dati al posto giusto in una successiva sessione. Il risultato è quindi un CD sempre leggibile, ma al quale è possibile aggiungere altri dati.

Il rovescio della medaglia è innanzitutto un certo spreco di spazio: all'inizio di ogni sessione viene registrata una sequenza di 4500 settori di zeri detta lead-in, seguita da un'altra sequenza di 150 settori di zeri detta pre-gap, mentre alla fine, dopo i dati, viene registrata una sequenza di 2250 settori di zeri detta lead-out. Solo nella prima sessione mancano il lead-in e il pre-gap, e il lead-out copre 6750 settori invece di 2250 (6500 in più).

Si vede dunque che, fra la prima e la seconda sessione, occorrono, oltre allo spazio occupato dai dati della prima sessione, 6750 + 4500 + 150 = 11400 ulteriori settori, mentre fra le sessioni successive gli ulteriori settori necessari sono 2250 + 4500 + 150 = 6900. Rispettivamente, in termini di megabyte, si tratta di circa 22Mb dopo la prima sessione e di circa 13Mb dopo le successive. Se si prevede di aggiungere sempre sessioni molto più piccole di 13Mb, è opportuno considerare bene questa scelta.

Un altro svantaggio dei CD multisessione è la difficoltà di accesso alle singole sessioni: è facile accedere a tutte le sessioni che precedono una sessione a scelta, ma è più difficile accedere ad una sessione escludendo tutte le altre, anche se questa necessità è piuttosto rara.

Infine, si ricordi che un CD multisessione non è sempre leggibile con qualunque dispositivo, specialmente nel caso di CD audio. In generale, invece, non ci sono problemi nel caso di CD dati.

Le operazioni da effettuare in questo caso sono piuttosto elementari. Se si dispone di due dispositivi distinti, uno per la lettura (SOURCE) e uno per la scrittura (TARGET), si può procedere come segue:

 dd if=SOURCE | cdrecord -data dev=TARGET -

Se invece si dispone di un unico dispositivo, occorre separare la fase di lettura da quella di scrittura, salvando il risultato della lettura in un file temporaneo (IMAGE):

 dd if=SOURCE of=IMAGE
 cdrecord -dev=SOURCE IMAGE

In dettaglio, i parametri in maiuscolo hanno il seguente significato:

SOURCE

è il nome del dispositivo da cui leggere i dati. Esso usa la normale notazione dei dispositivi in GNU/Linux. Nomi plausibili sono /dev/scd0 oppure /dev/hdc, ma in ogni caso non è ammessa la notazione SCSI, né si può fare riferimento a dispositivi a carattere, perché il comando dd opera per blocchi.

TARGET

identifica il dispositivo di incisione contenente il mezzo fisico su cui verranno effettivamente incisi i dati. In questo caso è ammessa la notazione SCSI e il riferimento a dispositivi a carattere, entrambi gestiti da cdrecord.

IMAGE

un file che conterrà l'immagine ISO9660 del disco sorgente, che verrà poi incisa sul disco destinazione.

Il comando dd usato sopra potrebbe essere sostituito da qualunque altro comando in grado di copiare su disco rigido l'intero file system presente sul CD originale. Ma in questo modo si trasformerebbe il file system ISO9660 presente sul CD originale in un file system diverso (ad esempio ext2 o reiser), dal quale poi si dovrebbe ricavare una nuova immagine ISO da incidere. Il comando dd evita questo passaggio, normalmente inutile, perché copia il contenuto del dispositivo a basso livello, ignorando completamente il tipo e la struttura del file system, e riproducendolo integralmente.

È il caso di notare, nel primo caso illustrato, l'importanza del trattino ('-') finale, che segnala a cdrecord di prelevare i dati da incidere dall'output del comando precedente, in questo caso appunto dd.

Anche disponendo di due dispositivi distinti, potrebbe essere prudente separare comunque la lettura dalla scrittura, e provare a montare nel file system l'immagine IMAGE, tramite il comando:

 mount -o loop IMAGE MOUNTPOINT

in cui MOUNTPOINT è una qualunque directory, tipicamente una sottodirectory di /mnt. Se questo comando non riporta errori, si può navigare nella directory MOUNTPOINT per verificare che il suo contenuto corrisponda a quello del CD originale, e solo dopo procedere alla scrittura. Il semplice fatto che mount non riporti errori è di solito indice di esito positivo della lettura: qualunque errore in lettura, anche minimo, comprometterebbe certamente la struttura ISO9660, e mount riporterebbe un messaggio d'errore.

Se è disponibile una checksum del CD originale, è opportuno calcolare la stessa checksum sull'immagine ottenuta, e verificare che le due siano uguali. Questa è ovviamente una verifica più significativa del semplice mount.

In generale, incidendo CD-RW, non è essenziale distinguere le due fasi, dal momento che, in caso di errori, il disco destinazione può essere riscritto. Incidendo invece CD-R, è prudente verificare l'affidabilità dei mezzi disponibili (lettore, masterizzatore e dischi) almeno per le prime volte, e poi regolarsi di conseguenza.

La creazione di un CD dati avviene in modo simile alla copia esatta. La differenza è che la sorgente non è un CD in formato ISO9660, bensì un file immagine, del tutto simile al file IMAGE che si ottiene durante la copia se questa viene effettuata in due passaggi. Tale file viene creato con il comando mkisofs a partire da una serie di directory o file, specificati come argomenti del comando stesso.

Nella situazione più semplice, e anche più comune, si procede come sotto:

 mkisofs -r SOURCE_1 [SOURCE_2 ... SOURCE_N] | cdrecord dev=TARGET -

Il parametro TARGET ha esattamente il significato visto a proposito della copia esatta. I parametri SOURCE_1,... SOURCE_N, di cui solo il primo è obbligatorio, sono tipicamente percorsi assoluti o relativi, non necessariamente corrispondenti a directory, anche se questa è la situazione più comune.

Anche in questo caso, è fondamentale il trattino finale, perché la pipe ('|') collega l'output di mkisofs, cioè l'immagine ISO delle directory specificate, allo standard input di cdrecord, che però deve essere informato di questo.

L'opzione -r è generalmente sufficiente ad ottenere risultati soddisfacenti nella maggior parte delle situazioni. Essa produce un'immagine non compatibile con l'ISO9660 puro, ma con la sua estensione più diffusa, nota come Rock Ridge extensions. Un'immagine di questo tipo può contenere nomi di file praticamente arbitrari, costituiti da un numero qualsiasi di caratteri di qualunque tipo, fatte salve le cautele relative al set di caratteri. Quest'ultimo potrebbe costituire un problema, ma è comunqe possibile specificare un set di caratteri con l'opzione -input-charset.

Se il CD deve essere letto in ambiente Windows, è possibile che si abbia qualche problema di compatibilità. L'opzione -J, che attiva altre estensioni proprietarie di Microsoft, note come Joliet extensions, potrebbe essere utile in questi casi.

Occorre tenere presente che l'uso delle estensioni Rock Ridge richiede la sostituzione dei nomi di file lunghi con nomi compatibili con ISO9660, e la creazione di una apposita tabella di corrispondenza. Nei casi più complessi, in cui sono raggruppati in una sola immagine molti file provenienti da directory diverse, questo può causare duplicazioni di nomi che mkisofs non è in grado di sciogliere.

La soluzione è l'uso dei cosiddetti graft-points, ma questo è piuttosto complesso, ed è opportuno in questi casi ricorrere ad un'interfaccia come xcdroast o altre che si occupano di invocare mkisofs con i parametri necessari ad evitare questi conflitti, il tutto in maniera trasparente all'utente.

Al costo di un certo spreco di spazio sul supporto, è possibile incidere più sessioni sullo stesso CD in fasi successive. Questo è particolarmente utile, ad esempio, a fini di backup: periodicamente si aggiunge una nuova sessione al CD già iniziato, contenente un archivio dei dati modificati dall'ultima sessione.

Non tutti i dispositivi offrono questa possibilità, ma il comando cdrecord -prcap dovrebbe fornire indicazioni chiare in proposito.

L'incisione della prima sessione non è molto diversa dall'incisione di un CD monosessione. Supponendo che IMAGE sia un'immagine ISO9660, ottenuta in qualsivoglia modo, essa dev'essere incisa con il comando

cdrecord dev=TARGET -multi IMAGE

Come si vede, l'unica differenza rispetto al CD monosessione è l'opzione -multi. A questo punto il CD può già essere montato nel filesystem, come se fosse un CD monosessione.

Per aggiungere una nuova sessione, non si può prescindere da mkisofs, perché la nuova immagine deve essere creata indicando a mkisofs alcuni parametri ricavati dalla sessione precedente. I comandi da usare, nella loro forma più semplice, sono i seguenti:

NEXT=$(cdrecord dev=TARGET -msinfo)
mkisofs -r -o IMAGE -C $NEXT -M TARGET SOURCE_1 ... SOURCE_N
cdrecord dev=TARGET -multi IMAGE

I parametri e le variabili in maiuscolo hanno il seguente significato:

TARGET

è il nome del dispositivo usato per incidere. Può assumere le varie forme già discusse sopra.

NEXT

se il supporto nel dispositivo contiene più di una sessione, questa variabile deve avere un valore del tipo X,Y, con X e Y numeri interi. Se il supporto contiene solo una sessione, X vale 0.

IMAGE

è l'immagine che sarà incisa come nuova sessione.

SOURCE_1... SOURCE_N

sono file e directory da aggiungere al CD, e che contribuiscono all'immagine IMAGE.

Come si vede, rispetto all'incisione di un CD monosessione, ogni nuova sessione di un CD multi-sessione richiede due nuove opzioni per mkisofs (-C e -M), che gli consentono di creare un'immagine che andrà a collocarsi al punto giusto del CD multi-sessione.

I dati contenuti in un CD multisessione possono essere estratti in due modi: si può accedere all'intero disco o alle singole sessioni. In entrambi la procedura più semplice prevede l'uso del comando mount.

Usato senza particolari opzioni, mount monta l'intero CD:

 mount DEV DIR

Nel comando sopra, DEV è il nome del file nella directory /dev che corrisponde al dispositivo di lettura. DIR è invece la directory su cui montare il CD. Un tipico esempio è:

mount /dev/hdc /mnt/cdrom

Fra l'altro, nella maggior parte dei casi è probabile che in /etc/fstab sia presente una riga equivalente all'esempio sopra, per cui dovrebbe essere sufficiente il comando:

mount /mnt/cdrom

A questo punto il contenuto del CD è completamente disponibile nella directory DIR, e sta all'utente decidere cosa farne. Ad esempio, può creare un nuovo CD multisessione in cui la prima sessione comprende l'intero contenuto del CD originale, recuperando tutto lo spazio vuoto necessario fra una sessione e l'altra. Questo può avere senso lavorando con CD-RW, ma non con CD-R.

Per montare una singola sessione occorre indicare a mount il numero di sessione tramite l'opzione -o session:

 mount -o session=NUM DEV DIR

Il parametro NUM indica il numero di sessione. La prima sessione di un CD è numerata con lo 0.

In realtà in questo modo non si accede a ciascuna singola sessione, ma a tutte quelle comprese fra la prima e quella selezionata. Questo è coerente con il fatto che, senza l'opzione -o session, viene montato l'intero CD, come se si fosse selezionata l'ultima sessione.

È teoricamente possibile accedere a singole sessioni di un CD multisessione, escludendo tutte le altre, ricorrendo al comando dd o al comando readcd.

Il problema, però, è che alcuni settori del CD sono creati in modo intenzionalmente non corretto per gestire le informazioni necessarie a recuperare correttamente il contenuto del CD.

Per evitare questo problema alla radice si possono incidere le varie sessioni con l'opzione -pad di cdrecord, che aggiungono 15 settori da 2048 byte alla fine di ogni sessione, sufficienti ad evitare che dd rilevi un errore di I/O.

Alcune fonti indicano che una soluzione migliore è ricorrere alla modalità di incisione DAO (Disc At Once). Altre fonti dicono però che non tutti i dispositivi sono in grado di incidere CD multisessione in modalità DAO, e operano invece in modalità TAO (Track At Once).

Occorre dunque fare delle prove per capire quali modalità sono gestite dal proprio dispositivo, o se la sola opzione -pad di cdrecord è sufficiente.

Per CD già incisi in modalità TAO, o senza opzione -pad, si può usare il comando readcd, fornito di norma insieme a cdrecord. La documentazione di cdrecord suggerisce, a proposito di readcd, due possibilità. Nel primo caso si procede come segue:

 cdrecord dev=SOURCE -toc
 readcd dev=SOURCE f=IMAGE sectors=$((LAST - 2))

In questi due comandi le variabili hanno il seguente significato:

SOURCE

è il nome del dispositivo contenente il CD da cui estrarre l'immagine ISO9660.

IMAGE

l'immagine ISO9660 ricavata dal CD.

LAST

è la posizione dell'ultimo settore dell'ultima sessione.

Come si vede, readcd richiede che i settori da leggere siano due meno della fine dell'ultima sessione.

Per duplicare un CD audio è necessario il comando cdparanoia oppure, in alternativa, il comando cdda2wav. Nel seguito si farà riferimento solo a cdparanoia.

Questo comando deve il suo nome all'uso di varie tecniche per cercare di rimediare a piccoli difetti del supporto. Il risultato sono copie molto fedeli, anche se, in presenza di originali particolarmente rovinati, il processo può essere molto lungo.

Per incidere la copia si usa ancora cdrecord, ma con l'opzione -audio. Nel caso più semplice, in presenza di due distinti dispositivi per la lettura e la scrittura, è sufficiente il comando seguente:

cdparanoia -q -d SOURCE 1- - | cdrecord dev=TARGET -audio -

in cui i parametri in maiuscolo hanno il seguente significato:

SOURCE

dispositivo contenente il CD audio. Esso è indicato con la notazione IDE, o anche con un dispositivo che sia un link ad un dispositivo IDE.

TARGET

dispositivo su cui incidere la copia. Per il suo nome si veda sopra.

Il comando illustrato legge e incide tutte le traccie, dalla prima all'ultima, grazie allo span argument 1-. Se il supporto per la copia non è un CD-RW, eventuali problemi in lettura potrebbero rendere impossibile completare la scrittura correttamente, e quindi il supporto per la copia potrebbe risultare inutilizzabile. Può essere più prudente operare in due fasi distinte, disponendo di sufficiente spazio su disco:

 cdparanoia -q -B -d SOURCE
 cdrecord dev=TARGET -audio track*.wav

OpenLDAP è un'implementazione libera e a sorgente aperto del protocollo LDAP (Lightweight Directory Access Protocol). È incluso in molte distribuzioni di GNU/Linux, ma è utilizzabile anche su altre piattaforme.

LDAP, come espresso chiaramente dal suo acronimo sciolto, è un protocollo di rete orientato soprattutto ai servizi di directory. Una directory, in astratto, è un contenitore di informazioni caratterizzato da:

• organizzazione gerarchica, come in un albero
• rare modifiche alle informazioni
• frequenti accessi alle informazioni

L'unità elementare di informazione in una directory è la entry. Ogni entry è unica all'interno della directory di cui fa parte, e si distingue una entry da un'altra attraverso i rispettivi distinguished name (dn).

Ogni entry, oltre al suo dn, può avere una serie di attributi. A seconda del tipo di informazioni che la directory deve contenere, i possibili attributi possono essere molto diversi.

Un insieme di attributi costituisce uno schema. In realtà uno schema è molto più di un semplice elenco di attributi: esso di solito specifica anche i valori che gli attributi possono assumere, nonché le relazioni possibili tra i diversi attributi, che possono essere sia gerarchiche sia trasversali.

Ad esempio, un tipico schema usato per gestire indirizzari stabilisce che una entry per la quale l'attributo objectclass abbia valore inetOrgPerson debba avere necessariamente un valore per l'attributo sn (surname).

La sintassi usata per definire gli schemi in LDAP è alquanto complessa, e di solito si tende ad usare schemi già disponibili. La sintassi permette infatti di ricavare, a partire da attributi già definiti, nuovi attibuti che ereditano dai primi tutte le loro caratteristiche, aggiungendone però di nuove.

Per fissare le idee, prima ancora di illustrare i comandi della suite OpenLDAP, è utile esaminare con un minimo di dettaglio un esempio concreto, non del tutto accademico.

Immaginiamo di dover gestire almeno gli indirizzi di alcune persone, in modo che siano accessibili dai client grafici di posta elettronica più diffusi, tutti in grado di accedere a delle directory tramite LDAP.

Per prima cosa, dobbiamo pensare a dei contenitori in cui collocare le diverse persone. Questi contenitori, secondo lo schema core, prendono il nome di organizationalUnit

....

In linea di principio, è possibile definire schemi per qualsiasi tipo di informazione si debba gestire, pur nei limiti stabiliti dalla sintassi cui si accennava sopra. Tuttavia, l'uso più tipico di LDAP consiste nella gestione di informazioni essenziali all'interno di una struttura operativa come un'azienda o un'istituzione, relative al personale, ai computer, alle stampanti, agli utenti, alle unità organizzative e così via.

In questa sezione su OpenLDAP si farà riferimento esclusivo a questo tipo di informazioni, e in particolare alla gestione delle persone, intese sia come persone fisiche, sia come utenti di vari sistemi informativi.