Appendice A. Ottenere FreeBSD

FreeBSD è disponibile in confezioni (i CD di FreeBSD, del software aggiuntivo, e la documentazione cartacea) presso svariati rivenditori:

I set di CD e DVD di FreeBSD sono disponibili presso molti rivenditori on-line:

Se sei un rivenditore e vuoi vendere i CDROM di FreeBSD, contatta uno dei distributori seguenti:

Il CVS Anonimo (anche conosciuto come anoncvs) è una caratteristica del programma di utilità CVS contenuto in FreeBSD che serve per sincronizzarsi con un deposito CVS remoto (in gergo repository CVS). Tra le altre cose, permette agli utenti di FreeBSD di realizzare, senza avere particolari permessi, operazioni CVS in sola lettura su uno dei server anoncvs ufficiali del progetto FreeBSD. Per utilizzarlo è sufficiente impostare la variabile di ambiente CVSROOT facendola puntare al server anoncvs appropriato, immettere la password "anoncvs" con il comando cvs login, e poi usare il comando cvs(1) per accederci come se fosse un deposito locale.

Benché si possa dire che i servizi CVSup e anoncvs realizzino sostanzialmente le stesse funzioni, ci sono vari particolari che possono influenzare la scelta di un metodo di sincronizzazione piuttosto dell’altro. Per dirla in breve, CVSup è più efficiente nell’uso delle risorse di rete ed è il più avanzato tecnicamente tra i due, ma tutto questo ha un prezzo. Per usare CVSup, bisogna installare e configurare un client speciale prima di poter scaricare qualcosa, e si può scaricare solo blocchi piuttosto grossi che CVSup chiama collezioni.

Anoncvs, al contrario, può essere usato per esaminare qualunque cosa a partire da un singolo file fino a uno specifico programma (come ls o grep) specificando il nome del modulo CVS. Ovviamente, anoncvs è adatto solo per operazioni di sola lettura sul deposito CVS, quindi se hai intenzione di supportare lo sviluppo locale in uno dei depositi condivisi del progetto FreeBSD allora CVSup è in realtà l’unica opzione.

La configurazione di cvs(1) per usare un deposito CVS Anonimo è semplicemente una questione di impostare la variabile di ambiente CVSROOT affinché punti a uno dei server anoncvs del progetto FreeBSD. Al momento della stesura di questo testo sono disponibili i seguenti server:

Dato che CVS permette di estrarre (nel suo gergo: "check out") qualsiasi versione dei sorgenti di FreeBSD che sia mai esistita (o, in alcuni casi, che esisterà), è bene familiarizzare con il parametro revisione (-r) di cvs(1) e sapere quali valori può assumere nel deposito del progetto FreeBSD.

Ci sono due tipi di tag, i tag di revisione e i tag di ramo. Un tag di revisione fa riferimento ad una revisione specifica. Il suo significato rimane lo stesso di giorno in giorno. Un tag di ramo, d’altro canto, si riferisce sempre all’ultima revisione relativa a una specifica linea di sviluppo. Dato che un tag di ramo non si riferisce ad una revisione specifica, esso potrebbe avere un significato diverso da un giorno con l’altro.

La Tag CVS contiene i tag di revisione che possono essere interessanti per gli utenti. Tuttavia, nessuno di questi tag è valido per la collezione dei port poichè questa non ha revisioni multiple.

Quando specifichi un tag di ramo, normalmente ricevi l’ultima versione dei file relativa a quella linea di sviluppo. Se vuoi ricevere una versione precedente, puoi farlo specificando la data con il parametro -D date. Si rimanda alla pagina man di cvs(1) per ulteriori dettagli.

Benché sia consigliata un’attenta lettura della pagina man di cvs(1) prima di fare qualsiasi cosa, seguono alcuni veloci esempi che spiegano in modo essenziale l’uso del CVS Anonimo:

Le seguenti risorse addizionali possono essere utili nell’apprendimento del CVS:

CTM fornisce una copia locale dell’albero dei sorgenti di FreeBSD. Ci sono molte "varietà" di alberi disponibili. Che tu voglia seguire l’intero albero CVS o solo uno dei rami, CTM può fornirti i dati che ti servono. Se sei uno sviluppatore attivo di FreeBSD, ma hai una connettività TCP/IP di bassa qualità o non esistente, o semplicemente desideri ricevere le modifiche in modo automatico, CTM fa al caso tuo. Riceverai fino a tre delta giornaliere per i rami più attivi. Tuttavia, puoi considerare che li puoi avere attraverso l’invio automatico di email. Le dimensioni degli aggiornamenti sono sempre più piccole possibile. Questi sono in genere meno di 5K, con occasionali (uno su dieci) aggiornamenti da 10-50K e qualcuno più grande (100K o più) di tanto in tanto.

Devi anche essere cosciente delle varie insidie relativi all’uso di sorgenti in via di sviluppo e non provenienti da release pronte. Questo è vero in particolare per i sorgenti "current" (correnti). È raccomandata la lettura di Restare in "current" con FreeBSD.

Ti servono due cose: il programma CTM, e le delta iniziali da dargli in pasto (per arrivare ai livelli della "current").

Il programma CTM fa parte di FreeBSD fin dalla release della versione 2.0 e, se hai una copia dei sorgenti disponibile, risiede in /usr/src/usr.sbin/ctm.

Le "delta" da dare in pasto a CTM si possono avere in due modi: tramite FTP o email. Se puoi utilizzare FTP via Internet allora i seguenti siti supportano l’accesso a CTM:

ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/

vedi anche la sezione mirror.

Entra via FTP nella directory giusta e, da lì, inizia col trasferire il file README.

Se invece desideri ricevere le delta per email:

Iscriviti ad una delle liste di distribuzione di CTM. ctm-cvs-cur-desc supporta l’interno albero CVS. ctm-src-cur-desc supporta il ramo di sviluppo current. mailing list di distribuzione CTM del ramo src 4-STABLE supporta il ramo della release 4.X, ecc. (Se non sai come iscriverti a una lista, clicca sul nome della lista o raggiungi la pagina https://lists.freebsd.org e clicca sulla lista a cui ti vuoi iscrivere. La pagina della lista dovrebbe contenere tutte le informazioni necessarie per l’iscrizione.)

Quando inizierai a ricevere gli aggiornamenti CTM via email, puoi usare il programma ctm_rmail per scompattarli e per applicarli. In realtà, se vuoi avere un processo completamente automatizzato, puoi usare il programma ctm_rmail direttamente in un elemento di /etc/aliases. Esamina la pagina man di ctm_rmail per maggiori dettagli.

Prima che tu possa servirti delle delta di CTM, hai bisogno di un punto di partenza dal quale successivamente costruire le delta.

Innanzitutto dovresti determinare ciò che hai. Si può iniziare da un directory "vuota". Devi usare una delta iniziale "Empty" per iniziare il tuo albero CTM. Qualche volta può succedere che una di queste delta "iniziali" sia distribuita su un CD per tua convenienza, ma comunque, questo generalmente non avviene.

Poichè gli alberi sono molte decine di megabyte, puoi iniziare da qualcosa che hai a portata di mano. Se hai un CD di una release, puoi copiare o estrarre i sorgenti da lì. Questo salverà un significativo trasferimento di dati.

Puoi riconoscere queste delta "iniziali" dalla lettera X preceduta da un numero (per esempio src-cur.3210XEmpty.gz). Il nome che segue la lettera X corrisponde all’origine del tuo "seme" iniziale. Empty è una directory vuota. Di solito una transizione base a partire da Empty è prodotta ogni 100 delta. Strada facendo, queste avranno grandi dimensioni! Le dimensioni comuni per le delta XEmpty vanno dai 70 a 80 Megabyte di dati compressi con gzip.

Una volta che ti sei procurato una delta base come punto di partenza, avrai bisogno anche di tutte le delta successive aventi un numero maggiore.

Per applicare le delta, fai come segue:

CTM decifra le delta compresse tramite il comando gzip, quindi non hai bisogno di decomprimerle con gunzip, e ciò salva spazio su disco.

Tranne in alcune circostanze, CTM non toccherà il tuo albero. Per verificare una delta puoi usare l’opzione -c e di fatto CTM non toccherà il tuo albero; verificherà soltanto l’integrità della delta e se questa può essere applicata in modo pulito al tuo albero attuale.

Ci sono altre opzioni di CTM, guarda la pagina man o ispeziona i sorgenti per maggiori dettagli.

Questo è davvero tutto ciò che devi sapere. Ogni volta che ottieni una delta, esegui CTM per aggiornare i tuoi sorgenti.

È meglio non rimuovere le delta che richiedono grandi tempi di scaricamento. Nel caso succeda qualche disgrazia non dovrai riscaricarle. Anche se hai solo dischetti floppy, considera l’uso di fdwrite per crearne una copia.

Allo stesso modo di uno sviluppatore potresti voler sperimentare delle modifiche nell’albero dei sorgenti. CTM supporta le modifiche locali in modo limitato: prima di verificare la presenza di un file foo, esso cerca foo.ctm. Se questo file esiste, CTM opererà su di esso piuttosto che su foo.

Questo comportamento offre un semplice modo per mantenere le modifiche locali: copia semplicemente il file che desideri modificare in un file con lo stesso nome e suffisso .ctm. Quindi puoi liberamente hackerare il codice, e CTM manterrà aggiornato il file .ctm.

I più importanti:

Esiste una serie di delta per la collezione dei ports, ma è ancora di poco interesse.

CTM/FreeBSD è disponibile via FTP anonimo dai siti mirror seguenti. Se decidi di procurarti CTM via FTP anonimo, per favore usa un sito a te vicino.

In caso di problemi, contatta la mailing list ctm-users-desc.

Se non trovi un mirror a te vicino o se il mirror è incompleto, prova ad usare qualche motore di ricerca come alltheweb.

CVSup è un pacchetto di software per distribuire ed aggiornare alberi di sorgenti da un deposito centrale CVS posto su un server remoto. I sorgenti di FreeBSD sono mantenuti in un deposito CVS su una macchina centrale di sviluppo situata in California. Con CVSup, gli utenti di FreeBSD possono facilmente mantenere aggiornati i loro alberi di sorgenti.

CVSup usa il cosiddetto modello ad estrazione per aggiornare. In questo modello, è compito del client chiedere al server gli aggiornamenti. Il server attente passivamente le richieste di aggiornamento dai suoi client. In questo modo tutti gli aggiornamenti sono incitati dal client. Il server non invia mai degli aggiornamenti che non sono stati richiesti. Gli utenti devono eseguire il client CVSup manualmente per ottenere un aggiornamento, oppure possono usare cron per eseguire automaticamente queste operazioni secondo stabilite regole.

Il termine CVSup, scritto in quel modo, si riferisce all’intero pacchetto di software. I suoi componenti principali sono il client cvsup che viene eseguito su ogni macchina degli utenti, e il server cvsupd che viene eseguito su ogni sito mirror di FreeBSD.

Leggendo la documentazione di FreeBSD e le mailling list, potresti notare dei riferimenti a sup. Sup è il predecessore di CVSup, e serviva per un simile scopo. CVSup sostanzialmente è usato allo stesso modo di sup e, di fatto, i suoi file di configurazione sono compatibili con sup. Sup non viene più utilizzato nel progetto FreeBSD, poichè CVSup è più veloce e più flessibile.

Il modo più semplice per installare CVSup è usare il package precompilato net/cvsup della collezione dei package di FreeBSD. Se preferisci costruire CVSup partendo dal sorgente, allora puoi usare il port net/cvsup. Ma sei avvisato: il port net/cvsup dipende dal sistema Modula-3, che richiede una consistente quantità di tempo e di spazio su disco per scaricarlo e costruirlo.

Il funzionamento di CVSup è controllato da un file di configurazione chiamato supfile. Esistono alcuni esempi di supfile nella directory /usr/shared/examples/cvsup/.

Le informazioni contenute in un supfile rispondono alle seguenti questioni relative a CVSup:

Nelle seguenti sezioni, costruiremo un tipico supfile per rispondere a turno ad ognuna di queste questioni. Incominciamo però col descrivere la struttura globale di un supfile.

Un supfile è un file di testo. I commenti iniziano con un # e si estendono fino alle fine della riga. Le righe bianche e le righe che contengono solo commenti sono ignorate.

Ogni altra riga descrive un insieme di file che l’utente vuole ricevere. Una riga inizia con il nome di una "collezione", un nome di un gruppo logico di file definiti dal server. Il nome della collezione indica al server i file che vuoi ricevere. Dopo il nome della collezione seguono zero o più campi, separati da spazi bianchi. Questi campi rispondono alle questioni citate in precedenza. Ci sono due tipi di campi: campo opzione e campo valore. Un campo opzione consiste di una parola chiave a se stante, es. delete o compress. Anche un campo valore inizia con una parola chiave, ma questa è seguita dal simbolo =, senza spazi bianchi intermedi, e da un seconda parola. Ad esempio, release=cvs è un campo valore.

Un supfile tipicamente specifica più di un’unica collezione da ricevere. Un modo di strutturare un supfile è specificare esplicitamente tutti i campi rilevanti per ogni collezione. Tuttavia, ciò tende a creare supfile troppo lunghi, e ciò è scomodo poichè in un supfile la maggior parte dei campi sono gli stessi per tutte le collezioni. CVSup fornisce un meccanismo per aggirare questi problemi. Le linee che iniziano con il nome speciale di pseudo-collezione *default possono essere usate per inizializzare opzioni e valori che saranno utilizzati come default per le successive collezioni definite nel supfile. Un valore di default può essere sovrascritto da una singola collezione, specificando un valore diverso per la collezione stessa. Inoltre i valori di default possono essere modificati in mezzo al supfile tramite linee *default aggiuntive.

Con queste conoscenze, possiamo ora procedere alla costruzione di un supfile per ricevere ed aggiornare l’albero dei sorgenti della FreeBSD-CURRENT.

Sei ora pronto per provare un aggiornamento. La riga di comando per farlo è molto semplice:

dove supfile è naturalmente il nome del supfile che hai creato. Assumendo che stai lavorando sotto X11, cvsup visualizzarà una GUI con alcuni bottoni adibiti ad operazioni usuali. Premi il bottone go, e stai a guardare l’esecuzione.

Poichè in questo esempio stai aggiornando il tuo albero dei sorgenti /usr/src, avrai bisogno di eseguire il programma come root affinchè cvsup abbia i permessi necessari per aggiornare i tuoi file. Avendo appena creato il tuo file di configurazione, e non avendo mai usato questo programma prima ad ora, tutto ciò potrebbe renderti un pò nervoso. Esiste un semplice modo per provare la sincronizzazione senza toccare i tuoi preziosi file. Crea una directory vuota in qualche posto, e richiamala come argomento sulla riga di comando:

La directory che hai specificato sarà usata come directory di destinazione per tutti gli aggiornamenti dei file. CVSup esaminerà i tuoi file usuali in /usr/src, ma non modificherà o cencellerà alcuno di essi. Gli aggiornamenti dei file finiranno invece in /var/tmp/dest/usr/src. Inoltre CVSup lascerà intatta la sua directory base contenente gli stati dei file quando viene eseguito in questo modo. Le nuove versioni di questi file saranno scritte nella directory specificata. A condizione che tu abbia l’accesso di lettura in /usr/src, non hai bisogno di essere root per realizzare questo tipo di giro di prova.

Se non stai utilizzando X11 o se non ti piacciono le GUI, dovresti aggiungere un paio di opzioni alla riga di comando quando esegui cvsup:

L’opzione -g indica a CVSup di non usare la sua GUI. Ciò è automatico se non stai utilizzando X11, ma se lo stai facendo allora la devi specificare.

L’opzione -L 2 indica a CVSup di visualizzare i dettagli di tutti gli aggiornamenti dei file che avvengono. Esistono tre livelli di verbosità, da -L 0 a -L 2. Il default è 0, che significa silenzio totale eccetto per i messaggi di errore.

Ci sono molte altre opzione disponibili. Per una breve lista di esse, digita cvsup -H. Per una descrizione più dettagliata, guarda la relativa pagina man.

Una volta che sei soddisfatto di come avvengono gli aggiornamenti, puoi organizzare esecuzioni regolari di CVSup usando cron(8). Ovviamente, non dovresti lasciare che CVSup usi la sua GUI quando lo esegui tramite cron(8).

Le collezioni di file disponibili via CVSup sono organizzate gerarchicamente. Ci sono poche collezioni grandi, le quali sono divise in piccole sotto-collezioni. Ricevere una grande collezione è equivalente a ricevere ogni sua sotto-collezione. Le relazioni gerarchiche tra le collezioni riflettono l’uso dell’identazione nella lista qui sotto.

Le collezioni maggiormente usate sono src-all, e ports-all. Le altre collezioni sono usate solo da piccoli gruppi di persone per scopi speciali, e alcuni siti mirror potrebbero non contenerle tutte.

Per le FAQ ed altre informazioni di CVSup vedere la pagina home di CVSup.

La maggior parte delle discussioni su CVSup inerenti a FreeBSD si svolgono sulla mailing list di discussioni tecniche su FreeBSD. In questa mailling list inoltre sono anche annunciate nuove versioni del software, come pure sulla mailing list di annunci su FreeBSD.

Questioni e resoconti di bug dovrebbero essere indirizzati all’autore del programma cvsup-bugs@polstra.com.

I server CVSup per FreeBSD si trovano ai seguenti siti:

Portsnap è un sistema per distribuire in modo sicuro l’albero dei port di FreeBSD. Circa ogni ora, viene generata una "snapshot" dell’albero dei port, che viene impacchettata e firmata criptograficamente. I file risultanti sono quindi distribuiti via HTTP.

Come CVSup, Portsnap usa un modello di aggiornamento a rchiesta: gli alberi dei port impacchettati e firmati sono messi sul server web che attende in modo passivo le richieste dei client. Gli utenti devono eseguire portsnap(8) manualmente o schedulare il job con cron(8) per scaricare periodicamente gli aggiornamenti in modo automatico.

Per ragioni tecniche, Portsnap non aggiorna direttamente il "reale" albero dei port in /usr/ports/; invece, lavora con una copia compressa dell’albero dei port memorizzata di default in /var/db/portsnap/. Questa copia compressa viene quindi usata per aggiornare l’albero dei port effettivo.

Su FreeBSD 6.0 e versioni più recenti, Portsnap è contenuto nel sistema base. Su versioni di FreeBSD più datate, può essere installato usando il port sysutils/portsnap.

Il funzionamento di Portsnap è controllato dal file di configurazione /etc/portsnap.conf. Per la maggior parte degli utenti, la configurazione di default sarà sufficiente; per maggiori dettagli, consultare la pagina man portsnap.conf(5).

La prima volta che portsnap(8) viene eseguito, ha bisogno di scaricare una snapshot compressa dell’intero albero dei port in /var/db/portsnap/ (o /usr/local/portsnap/ se Portsnap è stato installato dalla collezione dei port). Dall’inizio del 2006 la sua dimensione è di circa 41 MB.

Una volta che la snapshot compressa è stata scaricata, una copia dell’albero dei port può estratta in /usr/ports/. Questo è necessario perfino se l’albero dei port è già stato creato in quella directory (es., usando CVSup), poichè stabilisce un punto di inizio dal qualche portsnap può determinare quale parte dell’albero dei port necessita di essere aggiornata.

Dopo che una prima snapshot compressa dell’albero dei port è stata scaricata ed estratta in /usr/ports/, l’aggiornamento dell’albero dei port consiste in due passi: scaricando gli aggiornamenti della snapshot compressa, e usare questi per aggiornare l’albero dei port effettivo. Questi due passi possono essere specificati a portsnap con un comando singolo.

Al fine di evitare problemi di "affollamenti istantanei" accedendo ai server di Portsnap, portsnap fetch non funziona da un job cron(8). Esiste invece un comando apposito portsnap cron, che attende una durata random fino a 3600 secondi prima di scaricare gli aggiornamenti.

Inoltre, è fortemente racomandato che portsnap update non sia eseguito da un job cron, poichè è soggetto a causare problemi se viene avviato allo stesso tempo di compilazione o installazione di un port. Ad ogni modo, è possibile aggiornare i file INDEX dei port, e può essere fatto passando il flag -I a portsnap. (Ovviamente, se portsnap -I update viene eseguito da cron, sarà necessario eseguire successivamnte portsnap update senza la flag -I al fine di aggiornare il resto dell’albero.)

Aggiungendo la riga seguente in /etc/crontab, portsnap aggiornerà la snapshot compressa e i file INDEX in /usr/ports/, e manderà una email se qualche port installato non è aggiornato:

Tutti, con l’eccezione di HEAD (che è sempre un valido tag), sono relativi all’albero src/. Gli alberi ports/, doc/, e www/ non sono ramificati.

Questi tag si riferiscono a un preciso istante di tempo quando una versione di FreeBSD è stata rilasciata. Il processo di release engineering è documentato in dettaglio dai documenti Release Engineering Information e Release Process. L’albero src usa nomi di tag che iniziano con RELENG_. Gli alberi ports e doc usano tag il cui nome inizia con RELEASE. Infine, l’albero www non viene taggato con alcun nome particolare per le release.