diff --git a/it_IT.ISO8859-15/articles/committers-guide/Makefile b/it_IT.ISO8859-15/articles/committers-guide/Makefile index a48603f040..55c27c1cf7 100644 --- a/it_IT.ISO8859-15/articles/committers-guide/Makefile +++ b/it_IT.ISO8859-15/articles/committers-guide/Makefile @@ -1,29 +1,29 @@ # # $FreeBSD$ # # Crea la Nuova Guida per i Committer di FreeBSD # MAINTAINER=sysadmin@alexdupre.com DOC?= article FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= -JADEFLAGS+= -V %generate-article-toc% +WITH_ARTICLE_TOC?= YES # # SRCS lista i singoli files SGML che compongono il documento. Modifiche # a qualunque di questi files obbligano la ricreazione # # Contenuto SGML SRCS= article.sgml DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/it_IT.ISO8859-15/articles/committers-guide/article.sgml b/it_IT.ISO8859-15/articles/committers-guide/article.sgml index 9744e83a5e..b04d2f0dfa 100644 --- a/it_IT.ISO8859-15/articles/committers-guide/article.sgml +++ b/it_IT.ISO8859-15/articles/committers-guide/article.sgml @@ -1,1509 +1,1557 @@ %man; %freebsd; %authors; %teams; %mailing-lists; %translators; ]>
Guida del Committer The FreeBSD Italian Documentation Project $FreeBSD$ 1999 2000 2001 2002 + 2003 + The FreeBSD Italian Documentation Project Questo documento fornisce informazioni per la comunità dei committer di FreeBSD. Tutti i nuovi committer dovrebbero leggere questo documento prima di iniziare, e i committer già esistenti sono fortemente incoraggiati a riguardarselo di tanto in tanto. Traduzione a cura di &a.it.alex;. Dettagli Amministrativi Host con il Repository Principale - freefall.FreeBSD.org + ncvs.FreeBSD.org Metodi di Accesso - &man.ssh.1; + &man.ssh.1;, solo protocollo 2 CVSROOT Principale - /home/ncvs + ncvs.FreeBSD.org:/home/ncvs &a.cvs; Principali &a.peter; e &a.markm;, così come &a.joe; per i ports/ Mailing List - &a.developers;, &a.committers; + &a.developers;, &a.committers; + (Entrambe sono liste private; gli archivi possono essere trovati + in /home/mail/developers-archive + e /home/mail/committers-archive + sul cluster di FreeBSD.org.) + + + + Report mensili del Core Team + /home/core/public/monthly-report + sul cluster di FreeBSD.org. Tag CVS Degni di Nota RELENG_4 (4.X-STABLE), HEAD (-CURRENT) È richiesto l'uso di &man.ssh.1; o &man.telnet.1; con - Kerberos 5 per connettersi agli host con il repository. Questi sono - generalmente più sicuri che un semplice &man.telnet.1; o - &man.rlogin.1; visto che la negoziazione delle credenziali avverrà - sempre in modo cifrato. Tutto il traffico è cifrato di default + Kerberos 5 per connettersi agli host del progetto e solo &man.ssh.1;, + protocollo 2 ha il permesso di collegarsi all'host con il repository. + Questi sono generalmente più sicuri che un semplice &man.telnet.1; + o &man.rlogin.1; visto che la negoziazione delle credenziali + avverrà sempre in modo cifrato. + Tutto il traffico è cifrato di default con &man.ssh.1;. Insieme a programmi di utilità come &man.ssh-agent.1; e &man.scp.1;, anch'essi disponibili, &man.ssh.1; è di gran lunga più conveniente. Se non sai nulla di &man.ssh.1;, guarda la . Tipi di Bit di Commit Il repository CVS di FreeBSD ha un numero di componenti che, se combinati, supportano i sorgenti di base del sistema operativo, la documentazione, l'infrastruttura dei port delle applicazioni di terze parti, e vari programmi di utilità. Quando vengono assegnati i bit di commit di FreeBSD, vengono specificate le aree dell'albero dove il bit può essere usato. Solitamente, le aree associate a un bit corrispondono a quelle di chi ha autorizzato l'assegnamento del bit di commit. Ulteriori aree di autorità possono essere aggiunte in seguito: se occorrerà, il committer dovrà seguire le normali procedure di allocazione del bit di commit per quell'area dell'albero, chiedendo l'approvazione all'entità appropriata e possibilmente prendendo un mentore per quell'area per un po' di tempo. Tipo di Committer Responsabile Componenti dell'Albero src core@ src/, doc/ soggetta ad appropriata revisione doc - nik@ + doceng@ - doc/, src/ documentazione + doc/, www/, documentazione src/ ports portmgr@ ports/ I bit di commit assegnati prima dello sviluppo della nozione di aree di autorità possono essere usati in molte parti dell'albero. Tuttavia, il buon senso dice che un committer che non ha mai lavorato precedentemente in un'area dell'albero chieda una revisione del proprio lavoro prima di effettuare il commit, chieda l'approvazione del responsabile appropriato, e/o lavori d'accordo con un mentore. Dato che le regole sulla manutenzione del codice differiscono a seconda dell'area dell'albero, questo è per il bene del committer che lavora in un'area poco familiare tanto quanto per gli altri che lavorano sull'albero. I committer sono incoraggiati a chiedere la revisione del proprio lavoro come parte del normale processo di sviluppo, indifferentemente dall'area dell'albero in cui stanno lavorando. Operazioni sul CVS Si assume che tu abbia già familiarità con le operazioni di base di CVS. I &a.cvs; sono i proprietari del repository CVS e sono - responsabili di tutte le sue modifiche dirette allo - scopo di ripulire o sistemare dei gravi abusi di CVS da parte di un - committer. Nessun altro deve provare a toccare il repository - direttamente. Nel caso dovessi causare qualche problema al repository, + responsabili delle sue modifiche dirette allo scopo di ripulire o + sistemare dei gravi abusi di CVS da parte di un committer. + Nel caso dovessi causare qualche problema al repository, diciamo una errata operazione di cvs import o - cvs tag, non cercare - di sistemarla da solo! - Invia un messaggio ai &a.cvs; (o chiama uno di loro) ed esponi il problema - ad uno di loro invece. Gli unici che hanno il permesso di manipolare - direttamente i bit del repository sono i - repomeister. - - Le operazioni sul CVS solitamente sono fatte loggandosi su - freefall, assicurandosi che la variabile di ambiente - CVSROOT sia impostata a /home/ncvs, e + cvs tag, invia un messaggio ai &a.cvs; (o chiama uno di + loro) ed esponi il problema ad uno di loro. Gli unici che hanno il + permesso di manipolare direttamente i bit del repository sono i + repomeister. Non ci sono shell di login disponibili su + ncvs.FreeBSD.org, tranne che per i + repomeister. + + Le operazioni sul CVS sono fatte da remoto impostando la variabile di + ambiente CVSROOT a ncvs.FreeBSD.org:/home/ncvs + e la variabile CVS_RSH a ssh, e quindi effettuando le appropriate operazioni di check-out/check-in. Se desideri aggiungere qualcosa di totalmente nuovo (ad esempio dei sorgenti in contrib, ecc.), deve essere usato cvs import. Guarda come riferimento la pagina man di &man.cvs.1; per l'utilizzo. - Tieni presente che quando usi CVS su freefall, devi - impostare la tua umask a 2, - così come la variabile di ambiente CVSUMASK a - 2. Questo assicura che ogni nuovo file creato tramite - cvs add abbia i corretti permessi. - Se aggiungi un file o una directory e scopri che il file nel repository - ha i permessi errati (per essere precisi, tutti i file nel repository - dovrebbero essere modificabili dal gruppo ncvs), - contatta uno dei meister del repository come descritto sopra. - - Se sei abituato ad usare CVS da remoto e ti consideri abbastanza - pratico di CVS in generale, puoi anche effettuare le operazioni sul CVS - direttamente dalla tua macchina e dai tuoi sorgenti locali. - Ricordati solo di impostare CVS_RSH a - ssh così da usare un metodo di trasferimento - relativamente sicuro ed affidabile. Se non hai idea del significato di - quello che ho appena detto, allora continua a loggarti su - freefall ed ad applicare le tue diff con - &man.patch.1;. + + Per favore non usare cvs + checkout o update con la macchina con il + repository ufficiale impostata come CVS Root per tenere aggiornato il + tuo albero dei sorgenti. CVS da remoto non è ottimizzato per la + distribuzione via rete e richiede un grande sovraccarico di lavoro e di + amministrazione sul lato server. Utilizza il nostro metodo di + distribuzione avanzato cvsup per ottenere i bit del + repository, ed esegui solamente l'operazione di + commit sull'host con il repository. + Forniamo un'estesa rete di mirror cvsup per questo scopo, così + come diamo accesso al cvsup-master se hai veramente + bisogno di essere aggiornato alle ultime modifiche. + Il cvsup-master ha la potenza necessaria a gestire + questa cosa, il repository principale no. &a.jdp; è a capo del + cvsup-master. + + Molti committer definiscono l'alias fcvs che + si traduce in cvs -d + xxx@ncvs.FreeBSD.org:/home/ncvs per questo scopo. + In questo modo svolgono tutte le operazioni di CVS localmente ed usano + fcvs commit per effettuare il commit sull'albero CVS + ufficiale. + Se devi usare le operazioni add e delete di CVS come se fosse un'operazione &man.mv.1;, allora va effettuata una copia nel repository piuttosto che usare add e delete di CVS. In una copia nel repository, un CVS Meister copierà il/i file nei loro nuovi nomi e/o locazioni e ti avviserà ad operazione avvenuta. Lo scopo di una copia del repository è di preservare la cronologia dei cambiamenti del file, o i log. Noi del FreeBSD Project diamo molta importanza alla cronologia dei cambiamenti che CVS fornisce al progetto. Informazioni di riferimento, tutorial, e FAQ su CVS possono essere trovate su: http://www.cvshome.org/docs/, e anche le informazioni contenute nei capitoli di Karl Fogel da Open Source Development with CVS sono molto utili. &a.des; ha fornito inoltre il seguente mini manuale su CVS. Effettua il check out di un modulo con il comando co o checkout. &prompt.user; cvs checkout shazam Questo estrae una copia del modulo shazam. Se non c'è alcun modulo shazam nel file dei moduli, cercherà allora una directory di primo livello chiamata shazam. Opzioni utili con <command>cvs checkout</command> Non crea le directory vuote Estrae solo un livello, non le sottodirectory Estrai la versione, il ramo, o il tag ver Estrai i sorgenti com'erano in data data
Esempi pratici su FreeBSD: Estrai il modulo miscfs, che corrisponde a src/sys/miscfs: &prompt.user; cvs co miscfs Ora hai una directory chiamata miscfs con le sottodirectory CVS, deadfs, devfs, e così via. Una di queste (linprocfs) è vuota. Estrai gli stessi file, ma con il percorso completo: &prompt.user; cvs co src/sys/miscfs Ora hai una directory chiamata src, con le sottodirectory CVS e sys. src/sys ha le sottodirectory CVS e miscfs, ecc. Estrai gli stessi file, ma elimina le directory vuote: &prompt.user; cvs co -P miscfs Ora hai una directory chiamata miscfs con le sottodirectory CVS, deadfs, devfs... ma nota che non c'è nessuna sottodirectory linprocfs, perché non contiene alcun file. Estrai la directory miscfs, ma nessuna delle sue sottodirectory: &prompt.user; cvs co -l miscfs Ora hai una a directory chiamata miscfs con solo una sottodirectory chiamata CVS. Estrai il modulo miscfs com'è nel ramo 4.X: &prompt.user; cvs co -rRELENG_4 miscfs Puoi modificare i sorgenti ed effettuare il commit su questo ramo. Estrai il modulo miscfs com'era nella 3.4-RELEASE. &prompt.user; cvs co -rRELENG_3_4_0_RELEASE miscfs Non potrai effettuare il commit delle modifiche, visto che RELENG_3_4_0_RELEASE corrisponde ad un preciso istante di tempo, non a un ramo. Estrai il modulo miscfs com'era il 15 gennaio 2000. &prompt.user; cvs co -D'01/15/2000' miscfs Non potrai effettuare modifiche. Estrai il modulo miscfs com'era una settimana fa. &prompt.user; cvs co -D'last week' miscfs Non potrai effettuare modifiche. Tieni presente che cvs salva i metadati in sottodirectory chiamate CVS. Gli argomenti di e sono fissi, che vuol dire che cvs se li ricorderà in seguito, ad esempio quando farai un cvs update. Controlla lo stato dei file estratti con il comando status. &prompt.user; cvs status shazam Questo visualizza lo stato del file shazam o di ogni file nella directory shazam. Per ogni file, lo stato è uno fra: Up-to-date Il file à aggiornato e non è stato modificato. Needs Patch Il file non è stato modificato, ma c'è una nuova versione nel repository. Locally Modified Il file è aggiornato, ma è stato modificato. Needs Merge Il file è stato modificato, e c'è una nuova versione nel repository. File had conflicts on merge Ci sono stati conflitti l'ultima volta che il file è stato aggiornato, e non sono ancora stati risolti. Vedrai anche la versione e la data locale, il numero dell'ultima versione appropriata (ultima appropriata perché se hai una data, un tag o un ramo fissati, può non essere l'ultima versione), e i tag, le date o le opzioni applicate. - Dopo avere estratto qualcosa, aggiornalo con il comando + Dopo avere estratto qualcosa, puoi aggiornarlo con il comando update. &prompt.user; cvs update shazam Questo aggiorna il file shazam o il contenuto della directory shazam all'ultima versione sul ramo che hai estratto. Se hai estratto un preciso instante di tempo, non fa nulla a meno che i tag non siano stati spostati nel repository o qualche altra strana cosa sia in corso. Opzioni utili, in aggiunta a quelle elencate sopra, con checkout: Estrae ogni directory aggiuntiva mancante. Scarica l'ultima versione del ramo principale. Altre magie (guarda sotto). Se hai estratto un modulo con o , l'esecuzione di cvs update con un argomento differente di o o con selezionerà un nuovo ramo, una nuova versione o una nuova data. L'opzione elimina tutti i tag, le date o le versioni fissate mentre e ne impostano di nuove. Teoricamente, specificando HEAD come argomento di avrai lo stesso risultato di , ma è solo in teoria. L'opzione è utile se: qualcuno ha aggiunto delle sottodirectory al modulo che hai estratto dopo averlo estratto. hai estratto con , e dopo cambi idea e vuoi estrarre anche le sottodirectory. hai cancellato delle sottodirectory e vuoi estrarle nuovamente. Osserva l'output di cvs update con cura. La lettera all'inizio di ogni file indica cosa è stato fatto su di esso: U Il file è stato aggiornato senza problemi. P Il file è stato aggiornato senza problemi (vedrai questo solo quando lavorerai su un repository remoto). M Il file è stato modificato, ed è stato fuso senza conflitti. C Il file è stato modificato, ed è stato fuso con dei conflitti. La fusione è ciò che avviene quando estrai una copia di qualche codice sorgente, lo modifichi, quindi qualcun altro effettua il commit di un'altra modifica, e tu esegui cvs update. CVS nota che tu hai fatto dei cambiamenti locali, e cerca di fondere le tue modifiche con quelle fatte tra la versione che hai originariamente estratto e quella che stai aggiornando. Se i cambiamenti sono a due parti separate del file, solitamente non ci saranno problemi (sebbene il risultato possa non essere sintatticamente o semanticamente corretto). CVS stamperà una M davanti ad ogni file modificato localmente anche se non c'è una nuova versione nel repository, quindi cvs update è adatto per avere un resoconto di quello che hai cambiato in locale. Se appare una C, allora le tue modifiche sono in conflitto con i cambiamenti presenti nel repository (le modifiche sono sulle stesse righe, o righe vicine, o hai cambiato così tanto il file locale che cvs non è in grado di applicare le modifiche al repository). Dovrai allora andare a modificare il file a mano e risolvere i conflitti; questi saranno evidenziati da righe di simboli <, = e >. Per ogni conflitto, ci sarà una linea di demarcazione formata da sette < e il nome del file, seguita da una porzione di quello che il tuo file locale conteneva, seguita da una riga di separazione con sette =, seguita dalla porzione corrispondente presente nella versione del repository, seguita da una riga di separazione con sette > e il numero di versione che stai aggiornando. L'opzione è un po' voodoo. Aggiorna il file locale alla versione specificata come se avessi usato , ma non cambia il numero di versione o il ramo registrato del file locale. Non è realmente utile tranne quando usata due volte, nel qual caso fonderà le modifiche tra le due versioni specificate nella copia su cui stai lavorando. Per esempio, supponiamo che ti abbia effettuato il commit di una modifica a shazam/shazam.c in &os.current; e che più tardi tu voglia effettuare l'MFC. Le modifiche che vuoi fondere sono nella versione 1.15: Estrai la versione &os.stable; del modulo shazam: &prompt.user; cvs co -rRELENG_4 shazam Applica le modifiche tra la ver 1.14 e la 1.15: &prompt.user; cvs update -j1.14 -j1.15 shazam/shazam.c Quasi certamente avrai un conflitto a causa delle righe $Id$ (o nel caso di FreeBSD, $FreeBSD$), quindi dovrai modificare a mano il file per risolvere il conflitto (rimuovi le righe di separazione e la seconda linea $Id$, lasciando la linea $Id$ originale intatta). Guarda le differenze tra la versione locale e quella sul repository con il comando diff. &prompt.user; cvs diff shazam mostra ogni modifica che hai fatto al file o al modulo shazam. Opzioni utili con <command>cvs diff</command> Utilizza il formato diff unificato. Utilizza il formato diff contestuale. Visualizza i file mancanti o aggiunti.
Vorrai sempre utilizzare , visto che le diff unificate sono molto più semplici da leggere rispetto a quasi tutti gli altri formati (in alcune circostanze, le diff contestuali generate con l'opzione possono essere meglio, ma sono molto più voluminose). Una diff unificata consiste di una serie di parti. Ogni parte inizia con una riga con due caratteri @ e specifica dove si trovano le differenze nel file e su quante linee si estendono. Questa è seguita da un certo numero di righe; alcune (precedute da uno spazio) fanno parte del contesto; altre (precedute da un -) sono quelle eliminate e altre ancora (precedute da un +) sono quelle aggiunte. Puoi anche effettuare una diff con una versione differente rispetto a quella che hai estratto specificando la versione con o come per il checkout o l'update, o anche visualizzare le differenze tra due versioni arbitrarie (indipendentemente da quella che hai localmente) specificando due versioni con o . Guarda le righe di log con il comando log. &prompt.user; cvs log shazam Se shazam è un file, questo stamperà un'intestazione con le informazioni sul file, come la locazione nel repository dove il file è salvato, a quale versione è l'HEAD per questo file, in quali rami si trova il file, e qualsiasi tag valido per questo file. Quindi, per ogni versione del file, viene stampato un messaggio di log. Questo include la data e l'ora del commit, chi ha fatto il commit, quante righe sono state aggiunte e/o tolte, e alla fine il messaggio di log che il committer ha scritto quando ha inviato la modifica. Se shazam è una directory, allora le informazioni di log descritte sopra vengono stampate a turno per ogni file presente nella directory. A meno che tu abbia dato l'opzione a log, vengono stampati anche i log per tutte le sottodirectory di shazam, in maniera ricorsiva. Usa il comando log per vedere la storia di uno o più file, come è salvata nel repository CVS. Puoi anche usarlo per vedere il messaggio di log di una versione specifica, se aggiungi al comando log: &prompt.user; cvs log -r1.2 shazam Questo stamperà solamente il messaggio di log per la versione 1.2 del file shazam se è un file, oppure i messaggi di log per le versioni 1.2 di ogni file sotto shazam se è una directory. Guarda chi ha fatto cosa con il comando annotate. Questo comando visualizza ogni riga del file o dei file specificati, insieme all'utente che ha modificato più recentemente quella riga. &prompt.user; cvs annotate shazam Aggiungi nuovi file con il comando add. Crea il file, usa cvs add su di esso, quindi cvs commit. In modo analogo, puoi aggiungere nuove directory creandole e poi utilizzando cvs add su di esse. Nota che non c'è bisogno di usare il commit sulle directory. Rimuovi i file obsoleti con il comando remove. Rimuovi il file, quindi usa cvs rm su di esso, ed infine cvs commit. Effettua il commit con il comando commit o checkin. Opzioni utili con <command>cvs commit</command> Forza il commit di un file non modificato. Specifica un messaggio di commit sulla riga di comando anziché invocare un editor.
Usa l'opzione se ti accorgi che hai lasciato fuori informazioni importanti dal messaggio di commit. Buoni messaggi di commit sono importanti. Dicono agli altri perché hai fatto le modifiche che hai fatto, non solo qui ed ora, ma per mesi o anni quando qualcuno si chiederà perché dei pezzi di codice all'apparenza illogici o inefficienti sono entrati nel file sorgente. È inoltre un aiuto inestimabile per decidere su quali modifiche va effettuato l'MFC e su quali no. I messaggi di commit devono essere chiari, concisi, e fornire un ragionevole sommario per dare un'indicazione di cosa è stato cambiato e perché. I messaggi di commit devono fornire abbastanza informazioni affinché una terza parte possa decidere se la modifica è rilevante per lei e se debba leggere la modifica stessa. Evita di effettuare il commit di più modifiche scollegate in una volta sola. Questo rende difficile la fusione, e inoltre rende più complicato determinare quale modifica è colpevole se salta fuori un bug. Evita di effettuare il commit di correzioni di stile o di spaziatura insieme a correzioni di funzionalità. Questo rende difficile la fusione, e inoltre rende più complicato capire quali modifiche alle funzionalità sono state fatte. Nel caso di file di documentazione, può rendere il lavoro dei gruppi di traduzione più complicato, visto che diventa difficile per loro determinare esattamente quali modifiche al contenuto vanno tradotte. Evita di effettuare il commit di cambiamenti a più file con un unico messaggio generico o vago. Invece, effettua il commit di un file alla volta (o di piccoli gruppi di file correlati) con un messaggio di commit appropriato. Prima di effettuare il commit, devi sempre: verificare su che ramo stai effettuando il commit, tramite cvs status. revisionare i tuoi cambiamenti, con cvs diff Inoltre, devi SEMPRE specificare esplicitamente sulla riga di comando su quali file deve essere effettuato il commit, in modo da non toccare incidentalmente altri file non voluti - cvs commit senza argomenti effettuerà il commit di ogni modifica nella directory corrente ed ogni sottodirectory. Suggerimenti e trucchi aggiuntivi: Puoi inserire le opzioni più comunemente usate nel tuo ~/.cvsrc, come in questo caso: cvs -z3 diff -Nu update -Pd checkout -P Questo esempio dice: usa sempre il livello di compressione 3 quando si parla con un server remoto. Questo è un salvavita quando si lavora su una connessione lenta. usa sempre le opzioni (visualizza i file aggiunti o rimossi) e (formato diff unificato) con &man.diff.1;. usa sempre le opzioni (elimina le directory vuote) e (estrai le nuove directory) quando si effettua l'update. usa sempre l'opzione (elimina le directory vuote) quando si estrae. Usa lo script cdiff di Eivind Eklund per visualizzare le diff unificate. È un wrapper per &man.less.1; che aggiunge i codici colore ANSI per far risaltare le intestazioni delle sezioni, le righe rimosse e quelle aggiunte; il contesto rimane invariato. Inoltre espande i tab correttamente (i tab spesso appaiono errati nelle diff a causa del carattere aggiuntivo all'inizio di ogni riga). http://people.FreeBSD.org/~eivind/cdiff Semplicemente usalo al posto di &man.more.1; o &man.less.1;: &prompt.user; cvs diff -Nu shazam | cdiff Alternativamente alcuni editor come &man.vim.1; (editors/vim5) hanno il supporto al colore e quando vengono usati con l'evidenziazione della sintassi attiva evidenzieranno molti tipi di file, incluse le diff, le patch, - e i log cvs/rcs. + e i log CVS/RCS. &prompt.user; echo "syn on" >> ~/.vimrc &prompt.user; cvs diff -Nu shazam | vim - &prompt.user; cvs log shazam | vim - CVS è vecchio, arcano, complesso e buggato, e a volte esibisce comportamenti non deterministici che qualcuno sostiene siano la prova che CVS non sia niente di più di una manifestazione Newtoniana di una entità ultradimensionale sensibile. Non è umanamente possibile conoscere ogni dettaglio di CVS, quindi non essere dispiaciuto di chiedere aiuto all'Intelligenza Artificiale (&a.cvs;). Non lasciare il comando cvs commit nella modalità di inserimento del messaggio di commit per troppo tempo (più di 2–3 minuti). Questo blocca la directory in cui stai lavorando ed impedirà ad altri sviluppatori di effettuare commit nella stessa directory. Se devi digitare un messaggio di commit lungo, scrivilo prima di eseguire cvs commit, e inseriscilo successivamente. Convenzioni e Tradizioni Come nuovo committer ci sono alcune cose che dovresti fare all'inizio. Aggiungere te stesso alla sezione Developers della Contributors List e rimuovere te stesso dalla sezione Additional Contributors. Una volta fatto ciò, non dimenticarti di aggiungere la tua entity di autore in doc/en_US.ISO8859-1/share/sgml/authors.ent; usa le altre voci come esempio. Questo è un compito relativamente semplice, ma rimane una buona prima prova delle tue abilità con CVS. Aggiungi una voce per te stesso in www/en/news/news.xml. Guarda le altre voci che assomigliano a A new committer e segui il formato. Se hai una chiave PGP o GnuPG, potresti volerla aggiungere in doc/en_US.ISO8859-1/books/handbook/pgpkeys. &a.des; ha scritto uno script di shell per rendere questa operazione molto semplice. Guarda il file README per maggiori informazioni. Alcune persone aggiungono una voce per se stessi in ports/astro/xearth/files/freebsd.committers.markers. Alcune persone aggiungono una voce per se stessi in src/usr.bin/calendar/calendars/calendar.freebsd. Presentati agli altri committer, altrimenti nessuno avrà idea di chi tu sia o di cosa ti occupi. Non devi scrivere una biografia completa, basta un paragrafo o due su chi sei e su quello di cui hai intenzione di occuparti come committer di FreeBSD. Invialo alla &a.developers; e sarai sulla strada giusta! Loggati su hub.FreeBSD.org e crea un file /var/forward/utente (dove utente è il tuo nome utente) contenente l'indirizzo e-mail dove vuoi che i messaggi indirizzati a tuonomeutente@FreeBSD.org siano inoltrati. Questo include tutti i messaggi di commit così come ogni altro messaggio inviato alla &a.committers; e alla &a.developers;. Caselle di posta veramente grandi che hanno preso residenza fissa su hub spesso vengono accidentalmente troncate senza preavviso, quindi inoltra o leggi i messaggi in modo da non perderli. Se sei iscritto alla &a.cvsall;, probabilmente vorrai disiscriverti per evitare di ricevere copie doppie dei messaggi di commit e della loro evoluzione. Tutti i nuovi committer hanno un mentore assegnato a loro per i primi mesi. Il tuo mentore è più o meno responsabile di spiegarti ogni cosa ti sia poco chiara ed è anche responsabile delle tue azioni durante questo periodo iniziale. Se fai un commit errato, imbarazzerai il tuo mentore e probabilmente dovresti passare almeno i primi commit a lui prima di agire direttamente sul repository. Tutti i commit dovrebbero andare su &os.current; prima di essere fusi in &os.stable;. Nessuna nuova caratteristica importante o modifica ad alto rischio dovrebbe essere fatta sul ramo &os.stable;. Relazioni tra Sviluppatori Se stai lavorando direttamente sul tuo codice o su codice che è già stabilito essere di tua responsabilità, allora c'è probabilmente poca necessità di confrontarsi con altri committer prima di effettuare un commit. Se vedi un bug in un'area del sistema che è chiaramente orfana (e ce n'è qualcuna di queste aree, per nostra vergogna), agisci allo stesso modo. Se, tuttavia, stai per modificare qualcosa che è chiaramente mantenuto attivamente da qualcun'altro (ed è solo guardando la mailing list cvs-committers che puoi veramente sapere cosa è e cosa non è) allora invia le modifiche a lui, come avresti fatto prima di diventare committer. Per i port, dovresti contattare il MAINTAINER specificato nel Makefile. Per altre parti del repository, se non sei sicuro di chi possa essere il maintainer attivo, potrebbe essere utile scorrere l'output di cvs log per vedere chi ha effettuato delle modifiche in passato. &a.fenner; ha scritto un utile script di shell che può aiutare a determinare chi sia il maintainer attivo. Questo elenca ogni persona che ha effettuato commit su un file specifico con il numero di commit che ha fatto. Può essere trovato su freefall in ~fenner/bin/whodid. Se alle tue richieste non corrisponde una risposta o se il committer in altro modo dimostra uno scarso interesse nell'area oggetto della modifica, vai avanti ed effettua il commit tu stesso. Se non sei sicuro di un commit per qualunque motivo, fallo revisionare da -hackers prima di effettuare il commit. Meglio che sia criticato lì piuttosto che quando è parte del repository CVS. Se ti capita di effettuare un commit che provoca controversie, potresti voler considerare l'annullamento delle modifiche finché il problema sia chiarito. Ricorda – con CVS possiamo sempre tornare indietro. + + Non mettere in dubbio le intenzioni di qualcuno che non è + d'accordo con te. Se vedono una soluzione differente dalla tua per un + problema, o anche un problema diverso, non è perché sono + stupidi, perché hanno una dubbia origine, o perché stanno + cercando di distruggere il tuo duro lavoro, la tua immagine personale, o + FreeBSD, ma semplicemente perché hanno una visione differente del + mondo. La diversità è una buona cosa. + + Dissenti onestamente. Argomenta la tua posizione con i suoi meriti, + sii onesto sui difetti che può avere, e sii disponibile a guardare + le loro soluzioni, o anche le loro visioni del problema, con mente + aperta. + + Accetta le correzioni. Possiamo tutti sbagliare. Se hai fatto un + errore, scusati e vai avanti con la tua vita. Non picchiarti, e + sicuramente non picchiare gli altri per il tuo sbaglio. Non sprecare + tempo imbarazzandoti o recriminando, risolvi solo il problema e vai + avanti. + + Chiedi aiuto. Cerca (e dai) revisioni dagli altri. Uno delle cose + in cui dovrebbe eccellere il software open source è il numero di + occhi che lo scrutano; questo non è vero se nessuno + revisionerà il codice. GNATS Il FreeBSD Project utilizza GNATS per gestire i bug e le richieste di cambiamenti. Assicurati di usare edit-pr numero-pr su freefall quando effettui il commit di una correzione o di un suggerimento trovato in un PR GNATS per chiuderlo. È inoltre considerato gentile se trovi il tempo di chiudere ogni PR associato al tuo commit, se esistono. Puoi anche usare &man.send-pr.1; tu stesso per proporre qualsiasi cambiamento che pensi debba essere fatto, a seguito di una maggiore revisione da parte di altre persone. Puoi trovare di più su GNATS su: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html http://www.FreeBSD.org/support.html - - http://www.FreeBSD.org/send-pr.html - - &man.send-pr.1; Puoi far girare una copia locale di GNATS, e poi integrare l'albero GNATS di FreeBSD in esso tramite CVSup. In seguito puoi usare i comandi GNATS localmente, o usare altre interfacce, come tkgnats. Questo ti permette di interrogare il database dei PR senza bisogno di essere connesso a Internet. Utilizzo di un albero GNATS locale Se non stai già scaricando l'albero GNATS, aggiungi questa riga al tuo supfile, e riesegui &man.cvsup.1;. Nota che siccome GNATS non è sotto il controllo di CVS non ha tag, quindi se lo stai aggiungendo al tuo supfile esistente deve apparire prima di ogni voce tag= dato che queste rimangono attive una volta impostate. gnats release=current prefix=/usr Questo metterà l'albero GNATS di FreeBSD in /usr/gnats. Puoi usare un file refuse per controllare quali categorie ricevere. Per esempio, per ricevere solo i PR docs, metti questa riga in /usr/local/etc/cvsup/sup/refuse Il percorso preciso dipende dall'impostazione *default base nel tuo supfile. . gnats/[a-ce-z]* Il resto di questi esempi assume che tu abbia scaricato solo la categoria docs. Modificali quando è necessario, a seconda delle categorie che tieni in sincronia. Installa il port GNATS da ports/databases/gnats. Questo metterà le varie directory GNATS sotto $PREFIX/share/gnats. Crea un symlink per le directory GNATS che aggiorni tramite CVSup sotto la versione di GNATS che hai installato. &prompt.root; cd /usr/local/share/gnats/gnats-db &prompt.root; ln -s /usr/gnats/docs Ripeti tante volte quanto necessario, a seconda di quante categorie GNATS tieni in sincronia. Aggiorna il file categories di GNATS con queste categorie. Il file è $PREFIX/share/gnats/gnats-db/gnats-adm/categories. # Questa categoria è obbligatoria pending:Categoria per i PR errati:gnats-admin: # # Categorie di FreeBSD # -docs:Bug di Documentazione:nik: +docs:Bug di Documentazione:freebsd-doc: Esegui $PREFIX/libexec/gnats/gen-index per ricreare l'indice GNATS. L'output deve essere reindirizzato su $PREFIX/share/gnats/gnats-db/gnats-adm/index. Puoi fare questo periodicamente da &man.cron.8;, o eseguire &man.cvsup.1; da uno script di shell che fa anche questo. &prompt.root; /usr/local/libexec/gnats/gen-index \ > /usr/local/share/gnats/gnats-db/gnats-adm/index Verifica la configurazione interrogando il database dei PR. Questo comando visualizza i PR docs aperti. &prompt.root; query-pr -c docs -s open Anche altre interfacce, come quella fornita dal port databases/tkgnats, dovrebbero funzionare correttamente. Prendi un PR e chiudilo. Questa procedura funziona solo per permetterti di visualizzare ed interrogare i PR localmente. Per modificarli o chiuderli dovrai ancora loggarti su freefall e farlo da lì. Chi è Chi Oltre ai meister del repository, ci sono altri membri e team del FreeBSD Project che probabilmente arriverai a conoscere nel tuo ruolo di committer. Brevemente, e senza pretesa di elencarli tutti, questi sono: &a.jhb; John è il manager dell'SMPng Project, e ha autorità sulla progettazione architetturale e sull'implementazione del passaggio a un sistema di threading e locking del kernel a grana fine. È anche l'autore dell'SMPng Architecture Document. Se stai lavorando sullo stesso sistema, coordinati con John. Puoi imparare di più sull'SMPng Project dalla sua home page: http://www.FreeBSD.org/smp/ &a.jake;, &a.tmm; Jake e Thomas sono i maintainer del port sull'architettura sparc64. &a.nik; Nik supervisiona il Documentation Project. Oltre a scrivere documentazione mette insieme l'infrastruttura sotto doc/share/mk e i fogli di stile e il codice relativo sotto doc/share/sgml. Se hai domande su questi sei incoraggiato a inviarle attraverso la &a.doc;. I committer interessati a contribuire alla documentazione dovrebbero familiarizzare con il Documentation Project Primer. &a.ru; Ruslan è Mister &man.mdoc.7;. Se stai scrivendo una pagina man e hai bisogno di qualche suggerimento sulla struttura, o sul linguaggio di markup, chiedi a Ruslan. &a.bde; Bruce è lo Style Police-Meister. Quando fai un commit che poteva essere fatto meglio, Bruce sarà lì a dirtelo. Ringrazia che qualcuno lo sia. Bruce conosce anche molto bene gli standard applicabili a FreeBSD. &a.gallatin; &a.mjacob; &a.dfr; &a.obrien; Questi sono gli sviluppatori e i supervisori primari della piattaforma DEC Alpha AXP. &a.dg; David è il supervisore del sistema VM. Se hai in mente una modifica al sistema VM, coordinala con David. &a.dfr; &a.marcel; &a.peter; &a.ps; Questi sono i principali sviluppatori e supervisori della piattaforma Intel IA-64, ufficialmente conosciuta come l'Itanium Processor Family (IPF). &a.murray; &a.steve; &a.rwatson; &a.jhb; &a.bmah; + &a.scottl; Questi sono i membri del &a.re;. Questo team è responsabile di decidere i tempi delle release e controllare il processo di release. Durante i periodi di congelamento del codice, gli ingegneri di release hanno l'autorità finale su tutte le modifiche al sistema per quel ramo di cui si sta preparando la release. Se c'è qualcosa che vuoi sia fuso da &os.current; a &os.stable; (qualsiasi valore queste possano avere in un dato momento), queste sono le persone con cui devi parlare. Bruce è anche l'autore della documentazione di release (src/release/doc/*). Se effettui il commit di una modifica che pensi sia degna di menzione nelle note di release, assicurati che Bruce lo sappia. Meglio ancora, inviagli una patch con il tuo commento. &a.benno; Benno è il maintainer ufficiale del port per PowerPC. &a.brian; Maintainer ufficiale di /usr/sbin/ppp. &a.nectar; Jacques è il FreeBSD Security Officer e supervisiona il &a.security-officer;. &a.wollman; Se hai bisogno di consigli sulle oscure parti interne delle reti o non sei sicuro di qualche eventuale modifica al sottosistema di rete che hai in mente, Garrett è qualcuno con cui parlare. Garret è inoltre molto esperto sui vari standard applicabili a FreeBSD. &a.committers; cvs-committers è l'entità che CVS usa per inviarti tutti i messaggi di commit. Non devi mai inviare email direttamente a questa lista. Puoi solamente rispondere a questa lista quando i messaggi sono brevi e direttamente correlati a un commit. &a.developers; - developers comprende tutti i committer. Questa lista è - stata creata per essere un forum sulle questioni della + Tutti i committer sono iscritti a -developers. Questa lista + è stata creata per essere un forum sulle questioni della comunità dei committer. Esempi sono le votazioni per il Core, annunci, ecc. Questa lista non è intesa come posto per la revisione del codice o come rimpiazzo della &a.arch; o della &a.audit;. Infatti usarla in questo modo urta il FreeBSD Project dato che dà l'impressione di una lista privata dove vengono prese le decisioni generali che influenzano tutta la comunità che usa FreeBSD senza essere rese pubbliche. Ultimo, ma non per importanza mai e poi mai invia un messaggio alla &a.developers; mettendo in CC:/BCC: un'altra lista FreeBSD. Mai e poi mai invia un messaggio su un'altra mailing list mettendo in CC:/BCC: la &a.developers;. Fare questo può diminuire enormemente i benefici di questa lista. Inoltre, non pubblicare o inoltrare mai email inviate alla &a.developers;. L'atto di inviare un messaggio alla &a.developers; anziché a una lista pubblica significa che le informazioni contenute non sono ad uso pubblico. Guida Rapida a SSH Se stai usando FreeBSD 4.0 o successivo, OpenSSH è incluso nel sistema base. Se stai usando una release precedente, aggiorna ed installa uno dei port di SSH. In generale, probabilmente vorrai prendere OpenSSH dal port security/openssh. Potresti anche voler estrarre l'ssh1 originale dal port security/ssh, ma sii certo di porre la dovuta attenzione alla sua licenza. Nota che questi port non possono essere installati contemporaneamente. Se non vuoi digitare la tua password ogni volta che usi &man.ssh.1;, e usi chiavi RSA o DSA per autenticarti, &man.ssh-agent.1; è lì per la tua comodità. Se vuoi usare &man.ssh-agent.1;, assicurati di eseguirlo prima di utilizzare altre applicazioni. Gli utenti X, per esempio, solitamente fanno questo dal loro file .xsession o .xinitrc. Guarda &man.ssh-agent.1; per i dettagli. Genera un paio di chiavi con &man.ssh-keygen.1;. Le chiavi finiranno nella tua directory $HOME/.ssh. Invia la tua chiave pubblica ($HOME/.ssh/identity.pub) alla persona che ti sta configurando come committer in modo che possa inserirla nel file authorized_keys nella tua home directory su freefall (ad esempio, $HOME/.ssh/authorized_keys). Ora dovresti essere in grado di usare &man.ssh-add.1; per autenticarti una volta a sessione. Ti verrà richiesta la pass phrase della tua chiave privata, e quindi verrà salvata nel tuo agente di autenticazione (&man.ssh-agent.1;). Se non vuoi più avere la tua chiave salvata nell'agente, l'esecuzione di ssh-add -d la rimuoverà. Verifica facendo qualcosa come ssh freefall.FreeBSD.org ls /usr. Per maggiori informazioni, guarda security/openssh, &man.ssh.1;, &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, e &man.scp.1;. Il Lungo Elenco di Regole dei Committer di FreeBSD Traduzione in corso + + Supporto per Diverse Architetture + + Traduzione in corso + + FAQ Specifiche sui Port Traduzione in corso Benefici del Lavoro Traduzione in corso Domande Generali Traduzione in corso
diff --git a/it_IT.ISO8859-15/articles/euro/article.sgml b/it_IT.ISO8859-15/articles/euro/article.sgml index 139ee91f58..64033959d2 100644 --- a/it_IT.ISO8859-15/articles/euro/article.sgml +++ b/it_IT.ISO8859-15/articles/euro/article.sgml @@ -1,383 +1,390 @@ %man; %translators; ]>
Il simbolo dell'Euro su <systemitem class="osname">FreeBSD</systemitem> Aaron Kaplan
aaron@lo-res.org
 2002 + 2003 + The FreeBSD Italian Documentation Project $FreeBSD$ Questo documento cercherà di aiutarvi ad usare il nuovo simbolo dell'Euro presente sulla vostra nuova tastiera comprata all'inizio del 2002 per l'avvento della nuova valuta comune. Inizieremo dalle parti più importanti come essere in grado di visualizzare correttamente il simbolo in console. Le sezioni successive tratteranno la configurazione di specifici programmi come X11. Molti utili suggerimenti sono stati forniti da Oliver Fromm, Tom Rhodes e innumerevoli altri. Grazie! Senza di voi non sarebbe stato possibile realizzare questo articolo! Traduzione a cura di &a.it.dema;. L'Euro in 5 minuti Se avete già familiarità con la localizzazione come descritta nel Manuale di FreeBSD potreste essere interessanti solamente alle seguenti informazioni che vi consentiranno di iniziare velocemente ad usare l'Euro: ISO8859-15 Questa è una versione leggermente modificata della più comune mappa caratteri ISO8859-1. Include il simbolo dell'Euro. Usata per le variabili d'ambiente LANG e LC_CTYPE. iso15-8x16.fnt Il font per la console da usare con &man.vidcontrol.1; /usr/share/syscons/keymaps/*.iso.kbd Mappe di tastiera per le diverse lingue. Impostate la vostra variabile keymap in rc.conf ad una di queste mappe. LC_CTYPE Usata per impostare il corretto tipo di caratteri nelle vostre impostazioni locali. XkbLayout "lingua(euro)" - Opzione di configurazione di XFree86. + Opzione di configurazione di + XFree86. /usr/X11R6/lib/X11/fonts/*/fonts.alias Assicuratevi di modificare i nomi dei vostri file dei font di X11 a -*-..-*-iso8859-15 Nota generale Nelle sezioni seguenti ci riferiremo spesso a ISO8859-15. Questa è la notazione standard a partire da FreeBSD 4.5. Nelle versioni più vecchie la notazione standard era invece ISO_8859-15 oppure DIS_8859-15. Se state usando una versione di FreeBSD più vecchia, assicuratevi di guardare in /usr/share/locale/ per scoprire quale notazione è in uso nel vostro sistema. La console Configurare il font della console In base alla risoluzione e dimensione della vostra console dovrete mettere una delle seguenti linee in rc.conf: font8x16="iso15-8x16.fnt" # da /usr/share/syscons/fonts/* font8x14="iso15-8x14.fnt" font8x8="iso15-8x8.fnt" Questo imposterà effettivamente il font ISO8859-15 conosciuto anche come Latin-9. ISO8859-15 è una variazione di ISO8859-1. Potete notare la differenza tra i due esaminando il simbolo dell'Euro: il suo valore decimale è 164. Nell'ISO8859-1 noterete un cerchietto con quattro piccoli segnetti agli angoli. Questo è - spesso chiamato come "simbolo universale di valuta". Nell'ISO8859-15, - invece del cerchietto, avrete il simbolo dell'Euro. Per il resto i - font sono più o meno identici. + spesso chiamato simbolo universale di valuta. + Nell'ISO8859-15, invece del cerchietto, avrete il simbolo dell'Euro. + Per il resto i font sono più o meno identici. Al momento della stesura di questo articolo l'unico font utilizzabile sembra essere l'iso15-8x16.fnt. Gli altri sembrano avere l'aspetto dello ISO8859-1 sebbene il nome suggerisca altrimenti. Impostando questo font alcune applicazioni da console avranno - un aspetto "rovinato". Questo è dovuto al fatto che esse si + un aspetto rovinato. + Questo è dovuto al fatto che esse si aspettano di trovare un diverso set di font/caratteri come per esempio l'ANSI 850. Un tipico esempio è - /stand/sysintall. + sysinstall. Comunque questo non dovrebbe essere un problema nella maggior parte dei casi. Il vostro prossimo passo dovrebbe essere o riavviare il vostro sistema affinché i cambiamenti abbiano effetto oppure (manualmente) effettuare le modifiche nello stesso modo in cui avverrebbero all'avvio: &prompt.user; vidcontrol -f iso15-8x16.fnt Per controllare se il font è stato impostato eseguite il seguente piccolo script awk: #!/usr/bin/awk -f BEGIN { for(i=160;i<180;i++) printf"%3d %c\n",i,i } Il risultato dovrebbe mostrare il simbolo dell'Euro nella posizione 164. Configurare la vostra tastiera per l'Euro La maggior parte delle mappe di tastiera dovrebbe essere già correttamente impostata. Per esempio, se avete una tastiera italiana e vi funzionano le lettere accentate, potete tranquillamente saltare questa sezione visto che la tastiera mappa correttamente la combinazioni di caratteri, qualunque essa sia, (ad esempio: Alt Gr e ) al valore decimale 164. Se avete problemi la cosa migliore è controllare i file in /usr/share/syscons/keymaps/*.kbd. Il formato dei file delle mappe di tastiera è descritto in &man.keyboard.4;. &man.kbdcontrol.1; può essere usato per caricare una mappa personalizzata. Una volta che è stata trovata la corretta mappa di tastiera, dovete aggiungerla a /etc/rc.conf con la linea: keymap="it.iso" # o un'altra mappa Come spiegato in precedenza, questo passo probabilmente lo avete già fatto al momento dell'installazione (con sysinstall). In caso contrario, riavviate oppure caricate la nuova mappa con &man.kbdcontrol.1;. Per verificare la nuova mappatura della tastiera, passate ad una nuova console e al prompt di login, invece di loggarvi, provate a premere il tasto Euro. Se non funziona assicuratevi di aver correttamente impostato la giusta mappa di tastiera oppure inviate una segnalazione di bug con &man.send-pr.1;. - Al momento il tasto Euro non funziona ancora in - bash o + Al momento il tasto Euro non funziona ancora con + bash o tcsh. Correggere le variabili d'ambiente - Le shell (bash, tcsh) si basano sulla libreria &man.readline.3; - la quale a sua volta utilizza la variabile d'ambiente + Le shell (bash, + tcsh) si basano sulla libreria + &man.readline.3;, la quale a sua volta utilizza la variabile d'ambiente LC_CTYPE. LC_CTYPE deve essere impostata prima che la shell sia completamente operativa. Fortunatamente è sufficiente aggiungere la linea: export LC_CTYPE=it_IT.ISO8859-15 - al vostro file .bash_profile (bash), - oppure: + al vostro file .bash_profile + (bash), oppure: setenv LC_CTYPE it_IT.ISO8859-15 - al vostro file .login (tcsh). Naturalmente, + al vostro file .login + (tcsh). Naturalmente, it_IT deve essere sostituito con la vostra lingua. Poi, sloggatevi e riloggatevi nuovamente, e verificate che il tasto Euro funzioni. Già così la maggior parte delle applicazioni console dovrebbe funzionare correttamente col tasto Euro. Ulteriori configurazioni per programmi speciali come pine potrebbero essere comunque necessarie. Un'alternativa alla modifica di .login e .bash_profile è quella di impostare le variabili d'ambiente tramite &man.login.conf.5;. Questo approccio ha il vantaggio di assegnare classi di login a determinati utenti (esempio, utenti Francesi, utenti Tedeschi, ecc.) in un solo posto. Modificare X11 Modificate /etc/XF86Config secondo le seguenti istruzioni: Option "XkbLayout" "it(euro)" Come sempre, rimpiazzate it con la vostra lingua. Così facendo la tastiera dovrebbe essere configurata correttamente. Come in console, deve essere scelto il font adatto. Per le applicazioni KDE andate in KDE control center -> Personalization -> Country & Language -> Charset e cambiatelo in ISO8859-15. Simili modifiche si devono effettuare per kmail e altre applicazioni. Un'altra buona idea è modificare i vostri file fonts.alias. In particolar modo il font fixed dovrebbe essere modificato per usare la giusta mappa caratteri. Il file /usr/X11R6/lib/X11/fonts/misc/fonts.alias dell'autore è mostrato come esempio: ! $Xorg: fonts.alias,v 1.3 2000/08/21 16:42:31 coskrey Exp $ fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-15 (...) Come in console, applicazioni speciali hanno ancora i font - ISO8859-1 configurati nei loro rispettivi database xrdb. + ISO8859-1 configurati nei loro rispettivi database &man.xrdb.1;. Un esempio importante è xterm. Come regola generale è sufficiente cambiare il corrispondente file di configurazione in /usr/X11R6/lib/X11/app-defaults e aggiungere il font corretto. Ecco come fare per xterm. &prompt.root; cd /usr/X11R6/lib/X11/app-defaults/ &prompt.root; vi XTerm Aggiungete la seguente linea all'inizio del file: *font: -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-15 Infine, fate ripartire X e assicuratevi che i font siano visualizzati correttamente eseguendo il precedente script awk. Tutte le principali applicazioni dovrebbero rispettare la mappatura di tastiera e l'impostazione del font. Problemi non ancora risolti Naturalmente, l'autore gradirebbe ricevere i vostri commenti. Inoltre, fatemi almeno sapere se avete soluzioni per questi problemi irrisolti. - Descrivere metodi alternativi per configurare XFree86: + Descrivere metodi alternativi per configurare + XFree86: x11/xkeycaps Impostazioni in GNOME Impostazioni in XFCE Impostazioni per (X)Emacs Descrivere l'UTF-8 Descrivere libiconv come un buon sistema per convertire applicazioni da ISO8859-15 a UTF-{8,16}
diff --git a/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml b/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml index b65bd92208..a097002db1 100644 --- a/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml +++ b/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml @@ -1,593 +1,597 @@ %man; %translators; ]>
Panoramica su BSD Greg Lehey
grog@FreeBSD.org
 Nel mondo open source, la parola Linux è quasi sinonimo di Sistema Operativo, ma non si tratta del solo sistema operativo UNIX open source. Secondo l'Internet Operating System Counter, ad Aprile del 1999 il 31.3% delle macchine connesse in rete ha in esecuzione Linux. Il 14.6% fa girare BSD UNIX. Alcuni dei più grandi operatori del web, come Yahoo!, usano BSD. Il server FTP più affollato del mondo, ftp.cdrom.com, usa BSD per trasferire 1.4 TB di dati al giorno. Chiaramente questo non è un mercato di nicchia: BSD è un segreto ben mantenuto. Dunque, qual è il segreto? Perché BSD non è conosciuto meglio? Questo documento risponde a questa e ad altre domande. In questo documento, le differenze tra BSD e Linux verranno evidenziate così. Traduzione a cura di &a.it.surrender;. Cos'è BSD? BSD sta per Berkeley Software Distribution. È il nome delle distribuzioni di codice sorgente dell'Università della California, Berkeley, che erano originariamente estensioni al sistema operativo UNIX del settore Ricerca della AT&T. Molti progetti open source di sistemi operativi sono basati su una versione di questo codice sorgente noto come 4.4BSD-Lite. Inoltre, essi comprendono un gran numero di pacchetti provenienti da altri progetti Open Source, incluso, in particolare, il progetto GNU. L'intero sistema operativo comprende: Il kernel BSD, che gestisce lo scheduling dei processi, l'utilizzo della memoria, il supporto multiprocessore (SMP), i driver dei vari dispositivi, ecc. Diversamente dal kernel Linux, ci sono differenti kernel BSD con differenti caratteristiche. La libreria C, le API di base per il sistema. La libreria C BSD è basata su codice proveniente da Berkeley, non dal progetto GNU. Utilità come shell, file manager, compilatori e linker. Alcune delle applicazioni derivano dal progetto GNU, altre no. L'X Window System, che gestisce la visualizzazione grafica. L'X Window System usato nella maggior parte delle versioni di BSD viene mantenuto come un progetto separato, il progetto XFree86. Questo è lo stesso codice usato da Linux. BSD in genere non specifica un desktop grafico come GNOME o KDE, anche se questi sono disponibili. Molti altri programmi ed utilità. Cosa, un vero UNIX? I sistemi operativi BSD non sono cloni, ma derivati open source del sistema operativo UNIX dell'AT&T Research, che è anche l'antenato del moderno UNIX System V. Questo potrebbe sorprendere. Come è potuto accadere questo, se la AT&T non ha mai rilasciato il suo codice come open source? È vero che lo UNIX AT&T non è open source, e nel senso del copyright BSD in definitiva non è UNIX, ma d'altro canto l'AT&T ha importato sorgenti da altri progetti, in maniera rilevante dal Computer Sciences Research Group dell'Università della California a Berkeley, CA. Iniziato nel 1976, il CSRG ha iniziato a rilasciare nastri con il loro software, chiamandolo Berkeley Software Distribution o BSD. Le versioni iniziali di BSD consistevano principalmente di programmi utente, ma questo cambiò drammaticamente quando il CSRG sottoscrisse un contratto con la Defense Advanced Projects Research Agency (DARPA) per migliorare i protocolli di comunicazione della loro rete, ARPANET. I nuovi protocolli furono conosciuti come Internet Protocols, e in seguito come TCP/IP, ai nomi dei protocolli più importanti. La prima implementazione distribuita in maniera estesa fu parte di 4.2BSD, nel 1982. Nel corso degli '80, sorsero un certo numero di compagnie che producevano workstation. Molti preferirono usare UNIX su licenza piuttosto che sviluppare da soli un nuovo sistema operativo. In particolare, la Sun Microsystems rilicenziò UNIX ed implementò una versione commerciale di 4.2BSD, che chiamò SunOS. Quando alla AT&T stessa fu permesso di vendere UNIX commercialmente, cominciarono con una implementazione ridotta all'osso nota come System III, presto seguita da System V. Il codice fondamentale di System V non comprendeva la parte di rete, dunque tutte le implementazioni includevano software addizionale tratto da BSD, incluso il software legato al TCP/IP, ma anche utilità come la shell csh e l'editor vi. Complessivamente, questi miglioramenti furono conosciuti come le Estensioni Berkeley. Il nastro BSD conteneva codice AT&T e dunque richiedeva una licenza per il sorgente UNIX. Dal 1990, il finanziamento del CSRG si stava esaurendo, e se ne stava per affrontare la chiusura. Alcuni membri del gruppo decisero di rilasciare il codice BSD, che era Open Source, senza il codice proprietario della AT&T. Ciò accadde infine con il Networking Tape 2, in genere noto come Net/2. Net/2 non era un sistema operativo completo: mancava circa il 20% del codice del kernel. Uno dei membri del CSRG, William F. Jolitz, scrisse il codice rimanente e lo rilasciò all'inizio del 1992 come 386BSD. Allo stesso tempo, un altro gruppo di ex membri del CSRG formò una compagnia chiamata Berkeley Software Design Inc. e rilasciò una versione beta di un sistema operativo chiamato BSD/386, che era basato sugli stessi sorgenti. Il nome del sistema operativo è cambiato di recente in BSD/OS. 386BSD non divenne mai un sistema operativo stabile. Invece, due altri progetti se ne distaccarono nel 1993: NetBSD e FreeBSD. I due progetti presero inizialmente direzioni divergenti, a causa della differente pazienza nell'attendere miglioramenti a 386BSD: la gente di NetBSD cominciò all'inizio dell'anno, e la prima versione di FreeBSD non fu pronta fino alla fine dell'anno. Nel frattempo, i codici erano diventati abbastanza differenti da renderne difficile la fusione. Inoltre, i progetti avevano obiettivi differenti, come vedremo in seguito. Nel 1996, un ulteriore progetto, OpenBSD, si divise da NetBSD. Perché BSD non è più conosciuto? Per un certo numero di ragioni, BSD è relativamente sconosciuto: Gli sviluppatori BSD sono spesso più interessati a ripulire il loro codice che a fagli pubblicità. Molta della popolarità di Linux è dovuta a fattori esterni al progetto Linux, come la stampa, e le compagnie formate per fornire servizi relativi a Linux. Fino a poco tempo fa, la varie versioni di BSD open source non avevano tali spinte. Gli sviluppatori BSD tendono ad avere più esperienza di quelli di Linux, ed hanno meno interesse nel rendere il sistema facile da usare. I nuovi arrivati tendono a sentirsi più a loro agio con Linux. Nel 1992, l'AT&T citò in giudizio BSDI, il produttore di BSD/386, sostenendo che il prodotto conteneva codice sotto copyright della AT&T. Il caso fu risolto in tribunale nel 1994, ma lo spettro della causa continua a perseguitare alcune persone. Nel marzo 2000 un articolo pubblicato sul web sosteneva che il caso era stato concluso recentemente. Un dettaglio che venne chiarito dall'azione legale fu il nome: negli anni '80, BSD era stato conosciuto come BSD Unix. Con l'eliminazione delle ultima vestigia del codice AT&T da BSD, si era perso anche il diritto di usare il nome UNIX. Per questo noterete riferimenti nei libri al sistema operativo 4.3BSD UNIX ed al sistema operativo 4.4BSD. C'è una certa percezione che il progetto BSD sia frammentato e belligerante. Il Wall Street Journal parlò di balcanizzazione dei progetti BSD. Come per l'azione legale, questa percezione si basa principalmente su vecchie storie. Paragone tra BSD e Linux Dunque qual'è l'effettiva differenza tra, diciamo, Debian Linux e FreeBSD? Per l'utente medio, la differenza è sorprendentemente piccola: entrambi sono sistemi operativi tipo UNIX. Entrambi vengono sviluppati da progetti non commerciali (questo non si applica a molte altre distribuzioni di Linux, ovviamente). Nella sezione seguente, daremo un'occhiata a BSD e lo paragoneremo a Linux. La descrizione si applica molto da vicino a FreeBSD, che conta per un 80% delle installazioni BSD, ma le differenza da NetBSD ed OpenBSD sono piccole. Chi possiede BSD? Nessuna persona o società possiede BSD. Esso è creato e distribuito da una comunità di persone con grande preparazione tecnica e voglia di fare che contribuiscono da tutto il mondo. Alcuni dei componenti di BSD sono progetti open source gestiti da diversi responsabili. Come viene sviluppato ed aggiornato BSD? I kernel BSD vengono sviluppati ed aggiornati seguendo il modello di sviluppo open source. Ogni progetto mantiene un albero dei sorgenti liberamente accessibile in un Concurrent Versions System, un sistema di gestione delle versioni concorrenti, che contiene tutti i file sorgenti del progetto, inclusa la documentazione ed altri file inerenti. Il CVS permette agli utenti di estrarre (in sostanza, estrarre una copia di) ogni versione desiderata del sistema. Un grande numero di sviluppatori da tutto il mondo contribuisce al miglioramento di BSD. Essi sono divisi in tre grandi gruppi: I contributor scrivono codice o documentazione. Non gli è permesso di effettuare il commit (aggiungere codice) direttamente all'albero dei sorgenti. Affinché il loro codice sia incluso nel sistema, esso deve essere rivisto e controllato da uno sviluppatore registrato, noto come committer. I committer sono sviluppatori con accesso in scrittura all'albero dei sorgenti. Per poter divenire un committer, un individuo deve dimostrare abilità nell'area nella quale è attivo. È a discrezione del committer la volontà di confrontarsi con qualcuno prima di effettuare cambiamenti. In generale, un committer con esperienza può effettuare cambiamenti che sono ovviamente corretti senza interrogare nessuno. Ad esempio, un committer del progetto di documentazione può correggere errori tipografici o grammaticali senza un confronto con altri. D'altro canto, dagli sviluppatori che stanno per effettuare cambiamenti profondi o complessi ci si aspetta che sottopongano i cambiamenti a revisione prima di renderli effettivi. In casi estremi, un membro del core team, con una funzione simile a un Capo Architetto, può ordinare che i cambiamenti siano rimossi dall'albero, un processo noto come marcia indietro. Tutti i committer ricevono una lettera che descrive ogni modifica individuale, dunque non è possibile effettuare un commit segretamente. Il Core Team. FreeBSD e NetBSD hanno ognuno un core team che gestisce il progetto. I core team si sono modificati nel corso del progetto, ed i loro ruoli non sempre sono ben definiti. Non è necessario essere uno sviluppatore per far parte del core team, anche se è normale che sia così. Le regole per il core team variano da un progetto ad un altro, ma in generale chi ne fa parte ha più autorità nell'indirizzamento del progetto rispetto agli altri membri. Questa organizzazione differisce da Linux in vari modi: Nessuna persona controlla il contenuto del sistema. In pratica, questa differenza è sopravvalutata, poiché il Capo Architetto può richiedere che il codice sia rimosso, ed anche nel progetto Linux viene permesso a molte persone di effettuare cambiamenti. D'altra parte, c'è un deposito centrale, un punto singolo dove è possibile trovare i sorgenti dell'intero sistema, incluse tutte le vecchie versioni. I progetti BSD mantengono l'intero Sistema Operativo, non solo il kernel. Questa distinzione è utile solo marginalmente: né BSD né Linux sono utili senza applicazioni. Le applicazioni usate su BSD sono spesso le stesse usate su Linux. Come risultato di un mantenimento formalizzato di un singolo CVS per l'albero dei sorgenti, lo sviluppo di BSD è chiaro, ed è possibile accedere ad ogni versione del sistema dal numero di release o dalla data. Il CVS permette anche aggiornamenti incrementali del sistema: ad esempio, il repository di FreeBSD viene aggiornato più o meno 100 volte al giorno. La maggior parte dei cambiamenti sono piccoli. Release di BSD Ogni progetto BSD fornisce il sistema in tre release differenti. Come per Linux, alle release vengono assegnati dei numeri come 1.4.1 o 3.5. Inoltre, il numero di versione ha un suffisso che indica il suo scopo: la versione di sviluppo del sistema è chiamata CURRENT. FreeBSD assegna un numero alla CURRENT, ad esempio FreeBSD 5.0-CURRENT. NetBSD usa uno schema di denominazione leggermente differente ed aggiunge un suffisso di una singola lettera che indica i cambiamenti nell'interfaccia interna, ad esempio NetBSD 1.4.3G. OpenBSD non assegna un numero (OpenBSD-current). Tutti gli sviluppi del sistema vanno in questo ramo. A intervalli regolari, tra le due e le quattro volte all'anno, i progetti fanno uscire una versione RELEASE del sistema, disponibile su CD-ROM e come libero download da siti FTP, ad esempio OpenBSD 2.6-RELEASE o NetBSD 1.4-RELEASE. La versione RELEASE è intesa per gli utenti finali ed è la versione normale del sistema. NetBSD fornisce anche patch release, versioni con solo piccole correzioni, con una terza cifra, ad esempio NetBSD 1.4.2. Quando vengono trovati dei bug in una versione RELEASE, vengono corretti, e le correzioni vengono aggiunte all'albero del CVS. In FreeBSD, la versione risultante viene detta STABLE, mentre in NetBSD ed OpenBSD continua a chiamarsi RELEASE. Caratteristiche minori possono essere aggiunte a questo ramo dopo un periodo di test nel ramo CURRENT. In contrasto, Linux mantiene due alberi di codice differenti: la versione stabile e la versione di sviluppo. Le versioni stabili hanno un numero di versione pari, come 2.0, 2.2 o 2.4. Le versioni di sviluppo hanno numero di versione dispari, come 2.1, 2.3 o 2.5. In ogni caso, il numero è seguito da un ulteriore numero che indica la versione esatta. Inoltre, ogni venditore aggiunge i suoi programmi utente o le sue utilità, dunque anche il nome della distribuzione è importante. Ogni venditore di distribuzione assegna anche un numero di versione alla distribuzione, dunque una descrizione completa dovrebbe essere una cosa del tipo TurboLinux 6.0 con kernel 2.2.14 Quali versioni di BSD sono disponibili? In contrasto alle numerose distribuzioni Linux, ci sono solo tre BSD open source. Ogni progetto BSD mantiene il suo albero dei sorgenti ed il suo kernel. In pratica, comunque, ci sono meno divergenze tra i codici dei programmi utente dei vari progetti di quante ce ne siano in Linux. È difficile catalogare gli obiettivi di ogni progetto: le differenze sono molto soggettive. Di base, FreeBSD punta alle alte prestazioni e alla facilità d'uso per l'utente finale, ed è molto usato dai fornitori di contenuti web. Funziona su PC e processori Alpha della Compaq. Il progetto FreeBSD ha nettamente più utenti degli altri. NetBSD punta alla massima portabilità: of course it runs NetBSD, ovviamente ci gira NetBSD. Funziona su macchine che vanno dai palmtop ai grossi server, ed è anche stato usato dalla NASA in alcune missioni spaziali. È una scelta particolarmente buona per il vecchio hardware non Intel. OpenBSD punta alla sicurezza e alla purezza del codice: usa una combinazione dei concetti open source e un rigoroso controllo del codice per creare un sistema la cui correttezza sia dimostrabile, rendendolo la scelta di organizzazioni attente alla sicurezza come banche, borse e dipartimenti del governo statunitense. Come NetBSD, funziona su un gran numero di piattaforme. Ci sono anche altri due sistemi operativi BSD che non sono open source, BSD/OS e il Mac OS X della Apple: BSD/OS è il più antico dei derivati di 4.4BSD. Non è open source, anche se licenze per il codice sorgente sono disponibili ad un costo relativamente basso. Assomiglia a FreeBSD in molti sensi. Mac OS X è l'ultima versione del sistema operativo per la linea Macintosh della Apple - Computer Inc.. Diversamente dal resto del sistema - operativo, il kernel è open source. Come parte di questo - sviluppo, gli sviluppatori chiave della Apple hanno accesso come - committer all'albero dei sorgenti di FreeBSD. + Computer Inc.. L'anima BSD Unix di questo sistema + operativo, Darwin, è + disponibile come un sistema operativo open source completamente + funzionante per computer x86 e PPC. Il sistema grafico Aqua/Quartz + e molti altri aspetti proprietari di Mac OS X rimangono comunque + closed source. Numerosi sviluppatori di Darwin sono anche + committer di FreeBSD, e viceversa. Come differisce la licenza BSD dalla GNU Public? Linux è disponibile con licenza GNU General Public License (GPL), che è pensata per eliminare il software closed source. In particolare, ogni lavoro derivante da un prodotto rilasciato sotto GPL deve essere fornito anche con il codice sorgente, se richiesto. Al contrario, la licenza BSD è meno restrittiva: le distribuzioni dei soli binari sono permesse. Ciò è particolarmente attraente per le applicazioni embedded. Cos'altro dovrei sapere? Poiché sono disponibili meno applicazioni per BSD che per Linux, gli sviluppatori BSD hanno creato un pacchetto di compatibilità con Linux, che permette ai programmi per Linux di funzionare su BSD. Il pacchetto include sia modifiche al kernel, in modo da permettere l'esecuzione corretta di chiamate di sistema Linux, che file di compatibilità, come la libreria C. Non c'è una differenza notevole nella velocità di esecuzione tra una applicazione in esecuzione su una macchina Linux ed una applicazione in esecuzione su una macchina BSD con pari caratteristiche. La natura tutto da una sola fonte di BSD fa sì che gli aggiornamenti siano molto più semplici da gestire rispetto alla maggior parte dei casi in Linux. BSD gestisce gli aggiornamenti della versione di libreria fornendo moduli di compatibilità per le versioni precedenti, dunque è possibile eseguire binari di parecchi anni prima senza problemi. Cosa dovrei usare, BSD o Linux? Cosa significa tutto questo in pratica? Chi dovrebbe usare BSD, chi dovrebbe usare Linux? Questa è una domanda molto difficile a cui rispondere. Qui ci sono alcune linee guida: Se non è rotto, non aggiustarlo: se usi già un sistema operativo open source, e ne sei soddisfatto, probabilmente non c'è ragione di cambiare. I sistemi BSD, in particolare FreeBSD, possono avere prestazioni notevolmente migliori di Linux. Ma questo non avviene in tutti i campi. In molti casi, c'è una differenza minima nelle prestazioni. In alcuni casi, Linux può comportarsi meglio di FreeBSD. In generale, i sistemi BSD hanno una reputazione migliore di affidabilità, principalmente come risultato di una base di codice più maturo. La licenza BSD può essere più attraente della GPL. BSD può eseguire codice Linux, mentre Linux non può eseguire codice BSD. Come risultato, c'è più software disponibile per BSD che per Linux. Chi fornisce supporto, servizi, e training su BSD? BSD ha sempre supportato BSD/OS, e recentemente ha annunciato contratti di supporto per FreeBSD. Inoltre, ognuno dei progetti ha una lista di consulenti a pagamento: FreeBSD, NetBSD, e OpenBSD.
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml index 5fded72e1d..516a0ee65e 100644 --- a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml +++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml @@ -1,424 +1,424 @@ %man; ]>
Filtering Bridges Alex Dupre
sysadmin@alexdupre.com
 $FreeBSD$ Spesso è utile dividere una rete fisica (come una Ethernet) in due segmenti separati, senza dover creare sottoreti e usare un router per collegarli assieme. Il dispositivo che collega due reti insieme in questo modo è chiamato bridge. Un sistema FreeBSD con due interfacce di rete è sufficiente per raggiungere lo scopo. Un bridge funziona individuando gli indirizzi del livello MAC (indirizzi Ethernet) dei dispositivi collegati ad ognuna delle sue interfacce di rete e inoltrando il traffico tra le due reti solo se il mittente e il destinatario si trovano su segmenti differenti. Sotto molti punti di vista un brigde è simile a uno switch Ethernet con solo due porte. Perché usare un filtering bridge? Sempre più frequentemente, grazie all'abbassamento dei costi delle connessioni a banda larga (xDSL) e a causa della riduzione del numero di indirizzi IPv4 disponibili, molte società si ritrovano collegate ad Internet 24 ore su 24 e con un numero esiguo (a volte nemmeno una potenza di 2) di indirizzi IP. In situazioni come queste spesso è desiderabile avere un firewall che regoli i permessi di ingresso e uscita per il traffico da e verso Internet, ma una soluzione basata sulle funzionalità di packet filtering dei router può non essere applicabile, vuoi per problemi di suddivisione delle sottoreti, vuoi perché il router è di proprietà del fornitore di accesso (ISP), vuoi perché il router non supporta tali funzionalità. È in questi casi che l'utilizzo di un filtering bridge diventa altamente consigliato. Un firewall basato su bridge può essere configurato e inserito direttamente tra il router xDSL e il vostro hub/switch Ethernet senza alcun problema di assegnazione di indirizzi IP. La traduzione italiana di firewall è muro anti incendio, non muro di fuoco come molti pensano. Nel corso dell'articolo, comunque, manterrò i termini tecnici nella loro lingua originale in modo da non creare confusione o ambiguità. Metodi d'installazione Aggiungere le funzionalità di bridge a una macchina FreeBSD non è difficile. Dalla release 4.5 è possibile caricare tali funzionalità come moduli anziché dover ricompilare il kernel, semplificando di gran lunga la procedura. Nelle prossime sottosezioni spiegherò entrambi i metodi di installazione. Non seguite entrambe le istruzioni: le procedure sono a esclusione. Scegliete l'alternativa che meglio si adatta alle vostre esigenze e capacità. Prima di continuare è necessario assicurarsi di avere almeno due schede di rete Ethernet che supportino la modalità promiscua sia in ricezione che in trasmissione, difatti devono essere in grado di inviare pacchetti Ethernet con qualunque indirizzo, non solo il loro. Inoltre, per avere un buon rendimento, le schede dovrebbero essere di tipo PCI bus mastering. Le scelte migliori sono ancora le Intel EtherExpress Pro seguite dalle 3Com 3c9xx subito dopo. Per comodità nella configurazione del firewall può essere utile avere due schede di marche differenti (che usino drivers differenti) in modo da distinguere chiaramente quale interfaccia sia collegata al router e quale alla rete interna. Configurazione del Kernel Così avete deciso di utilizzare il più vecchio e collaudato metodo di installazione. Per prima cosa bisogna aggiungere le seguenti righe al file di configurazione del kernel: options BRIDGE options IPFIREWALL options IPFIREWALL_VERBOSE La prima riga serve a compilare il supporto per il bridge, la seconda il firewall e la terza le funzioni di logging del firewall. Adesso è necessario compilare e installare il nuovo kernel. Si possono trovare le istruzioni nella sezione Building and Installing a Custom Kernel dell'handbook. Caricamento dei Moduli Se avete deciso di usare il nuovo e più semplice metodo di installazione, l'unica cosa da fare è aggiungere la seguente riga al file /boot/loader.conf: bridge_load="YES" In questo modo all'avvio della macchina verrà caricato insieme al kernel anche il modulo bridge.ko. Non è necessario invece aggiungere una riga per il modulo ipfw.ko in quanto verrà caricato in automatico dallo script /etc/rc.network dopo aver seguito i passi della prossima sezione. Preparativi finali Prima di riavviare per caricare il nuovo kernel o i moduli richiesti (a seconda del metodo che avete scelto in precedenza), bisogna effettuare alcune modifiche al file /etc/rc.conf. La regola di default del firewall è di rifiutare tutti i pacchetti IP. Per iniziare attiviamo il firewall in modalità , in modo da verificare il suo funzionamento senza alcun problema di filtraggio pacchetti (nel caso stiate eseguendo questa procedura da remoto, tale accorgimento vi consentirà di non rimanere erroneamente tagliati fuori dalla rete). Inserite queste linee nel file /etc/rc.conf: firewall_enable="YES" firewall_type="open" firewall_quiet="YES" firewall_logging="YES" La prima riga serve ad attivare il firewall (e a caricare il modulo ipfw.ko nel caso non fosse già compilato nel kernel), la seconda a impostarlo in modalità (come descritto nel file /etc/rc.firewall), la terza a non visualizzare il caricamento delle regole e la quarta ad abilitare il supporto per il logging. Per quanto riguarda la configurazione delle interfacce di rete, il metodo più utilizzato è quello di assegnare un IP a solo una delle schede di rete, ma il bridge funziona egualmente anche se entrambe o nessuna delle interfacce ha IP settati. In quest'ultimo caso (IP-less) la macchina bridge sarà ancora più nascosta in quanto inaccessibile dalla rete: per configurarla occorrerà quindi entrare da console o tramite una terza interfaccia di rete separata dal bridge. A volte all'avvio della macchina qualche programma richiede di accedere alla rete, per esempio per una risoluzione di dominio: in questo caso è necessario assegnare un IP all'interfaccia esterna (quella collegata a Internet, dove risiede il server DNS), visto che il bridge verrà attivato alla fine della procedura di avvio. Questo vuol dire che l'interfaccia fxp0 (nel nostro caso) deve essere menzionata nella sezione ifconfig del file /etc/rc.conf, mentre la xl0 no. Assegnare IP a entrambe le schede di rete non ha molto senso, a meno che durante la procedura di avvio non si debba accedere a servizi presenti su entrambi i segmenti Ethernet. C'è un'altra cosa importante da sapere. Quando si utilizza IP sopra Ethernet ci sono due protocolli Ethernet in uso: uno è IP, l'altro è ARP. ARP permette la conversione dell'indirizzo IP di una macchina nel suo indirizzo Ethernet (livello MAC). Affinché due macchine separate dal bridge riescano a comunicare tra loro è necessario che il bridge lasci passare i pacchetti ARP. Tale protocollo non fa parte del livello IP, visto che è presente solo con IP sopra Ethernet. Il firewall di FreeBSD agisce esclusivamente sul livello IP e quindi tutti i pacchetti non IP (compreso ARP) verranno inoltrati senza essere filtrati, anche se il firewall è configurato per non lasciar passare nulla. Ora è arrivato il momento di riavviare la macchina e usarla come in precedenza: appariranno dei nuovi messaggi riguardo al bridge e al firewall, ma il bridge non sarà attivato e il firewall, essendo in modalità , non impedirà nessuna operazione. Se ci dovessero essere dei problemi, è il caso di scoprire ora da cosa derivino e risolverli prima di continuare. Attivazione del Bridge A questo punto, per attivare il bridge, bisogna eseguire i seguenti comandi (avendo l'accortezza di sostituire i nomi delle due interfacce di rete fxp0 e xl0 con i propri): &prompt.root; sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0 &prompt.root; sysctl net.link.ether.bridge_ipfw=1 &prompt.root; sysctl net.link.ether.bridge=1 La prima riga specifica tra quali interfacce va attivato il bridge, la seconda abilita il firewall sul bridge ed infine la terza attiva il bridge. A questo punto dovrebbe essere possibile inserire la macchina tra due gruppi di host senza che venga compromessa qualsiasi possibilità di comunicazione tra di loro. Se è così, il prossimo passo è quello di aggiungere le parti net.link.ether.[blah]=[blah] di queste righe al file /etc/sysctl.conf, in modo che vengano eseguite all'avvio della macchina. Configurazione del Firewall Ora è arrivato il momento di creare il proprio file con le regole per il firewall, in modo da rendere sicura la rete interna. Ci sono delle complicazioni nel fare questo, perché non tutte le funzionalità del firewall sono disponibili sui pacchetti inoltrati dal bridge. Inoltre, c'è una differenza tra i pacchetti che stanno per essere inoltrati dal bridge e quelli indirizzati alla macchina locale. In generale, i pacchetti che entrano nel bridge vengono processati dal firewall solo una volta, non due come al solito; infatti vengono filtrati solo in ingresso, quindi qualsiasi regola che usi oppure non verrà mai eseguita. Personalmente uso che è una sintassi più antica, ma che ha un senso quando la si legge. Un'altra limitazione è che si possono usare solo i comandi e per i pacchetti filtrati dal bridge. Cose avanzate come , o non sono disponibili. Queste opzioni possono ancora essere usate, ma solo per il traffico da e verso la macchina bridge stessa (sempre che le sia stato assegnato un IP). Nuovo in FreeBSD 4.0 è il concetto di stateful filtering. Questo è un grande miglioramento per il traffico UDP, che consiste tipicamente di una richiesta in uscita, seguita a breve termine da una risposta con la stessa coppia di indirizzi IP e numeri di porta (ma con mittente e destinatario invertiti, ovviamente). Per i firewall che non supportano il mantenimento di stato, non c'è modo di gestire questo breve scambio di dati come una sessione unica. Ma con un firewall che può ricordarsi di un pacchetto UDP in uscita e permette una risposta nei minuti successivi, gestire i servizi UDP è semplice. L'esempio seguente mostra come fare. La stessa cosa è possibile farla con i pacchetti TCP. Questo permette di evitare qualche tipo di attacco denial of service e altri sporchi trucchi, ma tipicamente fa anche crescere velocemente la tabella di stato. Vediamo un esempio di configurazione. Bisogna notare che all'inizio del file /etc/rc.firewall ci sono già delle regole standard per l'interfaccia di loopback lo0, quindi non ce ne occuperemo più ora. Le regole personalizzate andrebbero messe in un file a parte (per esempio /etc/rc.firewall.local) e caricate all'avvio modificando la riga del file /etc/rc.conf dove era stata definita la modalità con: firewall_type="/etc/rc.firewall.local" Bisogna specificare il path completo del file, altrimenti non verrà caricato con il rischio di rimanere tagliati fuori dalla rete. Per il nostro esempio immaginiamo di avere l'interfaccia fxp0 collegata all'esterno (Internet) e la xl0 verso l'interno (LAN). La macchina bridge ha assegnato l'IP 1.2.3.4 (è impossibile che il vostro ISP vi assegni un indirizzo di classe A di questo tipo, ma per l'esempio va bene). # Le connessioni di cui abbiamo mantenuto lo stato vengono fatte passare subito add check-state # Esclude le reti locali definite nell'RFC 1918 add drop all from 10.0.0.0/8 to any in via fxp0 add drop all from 172.16.0.0/12 to any in via fxp0 add drop all from 192.168.0.0/16 to any in via fxp0 # Permette alla macchina bridge di connettersi con chi vuole # (se la macchina è IP-less non includere questi comandi) add pass tcp from 1.2.3.4 to any setup keep-state add pass udp from 1.2.3.4 to any keep-state add pass ip from 1.2.3.4 to any # Permette agli host della rete interna di connettersi con chi vogliono add pass tcp from any to any in via xl0 setup keep-state add pass udp from any to any in via xl0 keep-state add pass ip from any to any in via xl0 # Sezione TCP # Permette SSH add pass tcp from any to any 22 in via fxp0 setup keep-state # Permette SMTP solo verso il mail server add pass tcp from any to relay 25 in via fxp0 setup keep-state # Permette i trasferimenti di zona solo dal name server secondario [dns2.nic.it] add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state # Lascia passare i controlli ident: # è meglio che aspettare che vadano in timeout add pass tcp from any to any 113 in via fxp0 setup keep-state # Permette connessioni nel range di "quarantena". add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state # Sezione UDP # Permette DNS solo verso il name server add pass udp from any to ns 53 in via fxp0 keep-state # Permette connessioni nel range di "quarantena". add pass udp from any to any 49152-65535 in via fxp0 keep-state # Sezione ICMP # Abilita le funzioni di 'ping' add pass icmp from any to any icmptypes 8 keep-state # Permette il passaggio dei messaggi di errori del comando 'traceroute' add pass icmp from any to any icmptypes 3 add pass icmp from any to any icmptypes 11 # Tutto il resto è sospetto add drop log all from any to any Coloro che hanno configurato un firewall in precedenza potrebbero aver notato che manca qualcosa. In particolare, non ci sono regole contro lo spoofing, difatti non abbiamo aggiunto: add deny all from 1.2.3.4/8 to any in via fxp0 Ovvero, non far entrare dall'esterno pacchetti che affermano di venire dalla rete interna. Questa è una cosa che solitamente viene fatta per essere sicuri che qualcuno non provi a eludere il packet filter, generando falsi pacchetti che sembrano venire dall'interno. Il problema è che c'è almeno un host sull'interfaccia esterna che non si può ignorare: il router. Solitamente, però, gli ISP eseguono il controllo anti-spoof sui loro router e quindi non ce ne dobbiamo preoccupare. L'ultima riga sembra un duplicato della regola di default, ovvero non far passare nulla che non sia stato specificatamente permesso. In verità c'è una differenza: tutto il traffico sospetto verrà loggato. Ci sono due regole per permettere il traffico SMTP e DNS verso il mail server e il name server, se ne avete. Ovviamente l'intero set di regole deve essere personalizzato per le proprie esigenze, questo non è altro che uno specifico esempio (il formato delle regole è spiegato dettagliatamente nella man page &man.ipfw.8;). Bisogna notare che, affinché relay e ns siano interpretati correttamente, la risoluzione dei nomi deve funzionare prima che il bridge sia attivato. Questo è un chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta scheda di rete. In alternativa è possibile specificare direttamente l'indirizzo IP anziché il nome host (cosa necessaria se la macchina è IP-less). Le persone che sono solite configurare un firewall probabilmente avranno sempre usato una regola o per i pacchetti ident (porta 113 TCP). Sfortunatamente, questa non è una scelta applicabile con il bridge, quindi la cosa migliore è lasciarli passare fino alla destinazione. Finché la macchina di destinazione non ha un demone ident attivo, questa tecnica è relativamente sicura. L'alternativa è proibire le connessioni sulla porta 113, creando qualche problema con servizi tipo IRC (le richieste ident devono andare in timeout). L'unica altra cosa un po' particolare che potete aver notato è che c'è una regola per lasciar comunicare la macchina bridge e un'altra per gli host della rete interna. Ricordate che questo è dovuto al fatto che i due tipi di traffico prendono percorsi differenti attraverso il kernel e di conseguenza anche dentro il packet filter. La rete interna passerà attraverso il bridge, mentre la macchina locale userà il normale stack IP per le connessioni. Perciò due regole per gestire due casi differenti. Le regole in via fxp0 funzionano in entrambi i casi. In generale, se usate regole attraverso il packet filter, dovrete fare un'eccezione per i pacchetti generati localmente, in quanto non entrano tramite nessuna interfaccia. Contributi Alcune parti di questo articolo sono state prese, tradotte e adattate da testi sui bridge, appartenenti alla documentazione di FreeBSD in lingua inglese, a cura di Nick Sayer e Steve Peterson. Un grosso ringraziamento va a Luigi Rizzo per l'implementazione delle funzionalità di bridging in FreeBSD e per il tempo che mi ha dedicato rispondendo ad alcune mie domande a riguardo.
diff --git a/it_IT.ISO8859-15/articles/multi-os/article.sgml b/it_IT.ISO8859-15/articles/multi-os/article.sgml index d805111b84..eeb91c490c 100644 --- a/it_IT.ISO8859-15/articles/multi-os/article.sgml +++ b/it_IT.ISO8859-15/articles/multi-os/article.sgml @@ -1,761 +1,764 @@ +%authors; %translators; ]>
Installazione e Utilizzo di FreeBSD con altri Sistemi Operativi Jay Richmond
jayrich@sysc.com
 6 Agosto 1996 Questo documento spiega come far coesistere felicemente FreeBSD con altri sistemi operativi come Linux, MS-DOS, OS/2, e Windows 95. Un ringraziamento speciale va a: Annelise Anderson andrsn@stanford.edu, Randall Hopper - rhh@ct.picker.com, e Jordan K. Hubbard - jkh@time.cdrom.com + rhh@ct.picker.com, e &a.jkh;. Traduzione a cura di &a.it.max;. Introduzione Molta gente non può far convivere questi sistemi operativi senza avere a disposizione un hard disk di grosse dimensioni, perciò sono state incluse informazioni speciali sui drive EIDE di grosse dimensioni. Poiché ci sono così tante combinazioni di possibili sistemi operativi e configurazioni di hard disk, la potrebbe esserti di aiuto più di altre. Contiene descrizioni di specifiche configurazioni che usano molteplici sistemi operativi. Questo documento assume che tu abbia già fatto posto sul tuo hard disk per un altro sistema operativo. Ogni volta che ripartizioni il tuo hard disk, corri il rischio di distruggere e quindi perdere i dati sulle partizioni originali. In ogni caso, se il tuo hard disk è completamente occupato dal DOS, potresti usare FIPS (incluso nel CDROM di FreeBSD nella directory - \TOOLS oppure via + \TOOLS oppure via ftp). Ti permette di ripartizionare il tuo hard disk senza distruggere i dati già contenuti. C'è anche un programma commerciale - chiamato Partition Magic, che ti permette di ridimensionare e cancellare - partizioni senza conseguenze. + chiamato Partition Magic, che ti permette + di ridimensionare e cancellare partizioni senza conseguenze. Panoramica sui Boot Manager Si tratta solo di brevi descrizioni dei diversi boot manager che potresti trovare. A seconda del tuo computer, potresti trovare utile usarne più di uno sullo stesso sistema. Boot Easy Questo è il boot manager standard fornito con FreeBSD. Ha la possibilità di far partire qualsiasi cosa, incluso BSD, OS/2 (HPFS), Windows 95 (FAT e FAT32), e Linux. Le partizioni vengono scelte con i tasti funzione (F1-F12). Boot Manager di OS/2 - Questo fa partire FAT, HPFS, FFS (FreeBSD), ed EXT2 - (Linux). Farà anche partire partizioni FAT32. Le partizioni + Questo fa partire FAT, FAT32, HPFS, FFS (FreeBSD), ed EXT2 + (Linux). Le partizioni vengono scelte usando i tasti freccia. L'OS/2 Boot Manager è l'unico ad usare una propria partizione separata, diversamente dagli altri, che usano il master boot record (MBR). Di conseguenza, deve essere installato prima del 1024esimo cilindro per evitare problemi di avvio. Può far partire Linux usando LILO quando questo è parte del settore di avvio, non dell'MBR. Leggi gli HOWTO di Linux sul World Wide Web per avere più informazioni su come far partire Linux con il boot manager di OS/2. OS-BS Questa è un'alternativa a Boot Easy. Ti dà più controllo sul processo di avvio, con la possibilità di impostare la partizione di default da cui partire e il timeout di avvio. La versione beta di questo programma ti permette di avviare scegliendo il sistema operativo con i tasti freccia. È incluso nel cd di FreeBSD nella directory \TOOLS oppure via ftp. LILO, o LInux LOader Questo è un boot manager limitato. Farà partire FreeBSD, sebbene siano necessari alcuni accorgimenti e sistemazioni nel file di configurazione. A proposito di FAT32 - FAT32 è il rimpiazzo al filesystem FAT incluso nella Release + FAT32 è il rimpiazzo al file system FAT incluso nella Release Beta SR2 di Microsoft, che dovrebbe essere installata con Windows 95 a partire dalla fine del 1996. Converte il - normale filesystem FAT e ti permette di usare cluster di + normale file system FAT e ti permette di usare cluster di dimensioni più piccole per hard disk di dimensioni maggiori. Inoltre FAT32 modifica il settore di avvio tradizionale e la tabella di allocazione, rendendola incompatibile con alcuni Boot Manager. Una Installazione Tipica Diciamo che ho due grandi hard disk EIDE e voglio installarci FreeBSD, Linux, e Windows 95. Ecco come potrei fare usando questi due hard disk: /dev/wd0 (Primo hard disk) /dev/wd1 (Secondo hard disk) Tutti e due hanno 1416 cilindri. Parto dalla partizione MS-DOS o dal dischetto di avvio di Windows 95 che contiene l'utility FDISK.EXE - e creo una piccola partizione primaria da 50 megabyte + e creo una piccola partizione primaria da 50 MB (35-40 per Windows 95, più un po' di spazio per respirare) sul primo disco. Creo anche una partizione più grande sul secondo hard disk per le applicazioni di Windows e per i dati. Faccio ripartire ed installo Windows 95 (più facile a dirsi che a farsi) sulla partizione C:. La prossima cosa che farò sarà installare Linux. - Non sono sicuro per le altre distribuzioni, ma la slackware include + Non sono sicuro per le altre distribuzioni, ma la Slackware include LILO (guarda la ). Quando ripartiziono il mio hard disk con l'fdisk di Linux, metterò tutto ciò che riguarda Linux sul primo hard - disk (probabilmente 300 mega per una partizione di + disk (probabilmente 300 MB per una partizione di root decente e un po' di spazio di swap). Dopo aver installato Linux, quando viene chiesto di - installare LILO, _ASSICURATI_ di installarlo sul + installare LILO, assicurati di installarlo sul settore di avvio della partizione di Linux, non nell'MBR (Master Boot Record). La parte rimanente di hard disk va a FreeBSD. Assicurati anche che la slice root di FreeBSD non vada oltre il 1024esimo cilindro. (Il 1024esimo - cilindro è circa intorno ai 528mb in un disco ipotetico, - il mio, di 720mb). Userò il resto dell'hard disk - (circa 270 mb) per /usr e - /. Il resto del secondo hard + cilindro è circa intorno ai 528 MB in un disco ipotetico, + il mio, di 720 MB). Userò il resto dell'hard disk + (circa 270 MB) per /usr e + /. Il resto del secondo hard disk (la grandezza varia a seconda di quanto spazio ho lasciato agli applicativi e ai dati per Windows quando ho creato la partizione nel primo passo) può - essere usata per /usr/src + essere usata per /usr/src e per lo spazio di swap. Se visualizzato con l'utility fdisk di Windows 95, l'hard disk dovrebbe risultare in questo modo: --------------------------------------------------------------------- Display Partition Information Current fixed disk drive: 1 Partition Status Type Volume_Label Mbytes System Usage C: 1 A PRI DOS 50 FAT** 7% 2 A Non-DOS (Linux) 300 43% Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes) Press Esc to continue --------------------------------------------------------------------- Display Partition Information Current fixed disk drive: 2 Partition Status Type Volume_Label Mbytes System Usage D: 1 A PRI DOS 420 FAT** 60% Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes) Press Esc to continue --------------------------------------------------------------------- ** Potrebbe essere FAT16 o FAT32 se stai usando l'aggiornamento OEM - SR2. (Guarda la ). + SR2. Guarda la . Installazione di FreeBSD. Assicurati di avviare il computer con il primo hard disk configurato con NORMAL nel BIOS. Se non è così, dovrai settare la vera geometria del disco all'avvio (per arrivare a fare ciò, fai partire Windows 95 e consulta Microsoft Diagnostics (MSD.EXE), o controlla il BIOS) con il parametro hd0=1416,16,63 dove 1416 è il numero di cilindri sull'hard disk, 16 è il numero di testine per traccia, o heads per track, e 63 è il numero di settori per traccia sul drive. Quando partiziono l'hard disk, cerco sempre di mettere Boot Easy sul primo hard disk. Non mi preoccupo del secondo hard disk, non parte nulla da quello. Al riavvio, Boot Easy dovrebbe riconoscere le tre partizioni avviabili, cioè quella DOS (ovvero Windows 95), Linux, e BSD (FreeBSD). Considerazioni Speciali Molti sistemi operativi sono molto pignoli su come e dove devono essere messi sull'hard disk. Windows 95 deve essere sulla prima partizione primaria sul primo hard disk. OS/2 fa eccezione. Può essere installato in una partizione primaria o estesa sul primo o sul secondo hard disk. Se non sei sicuro, mantieni la parte avviabile di partizione sotto il 1024esimo cilindro. Se installi Windows 95 su un sistema BSD esistente, questo distruggerà l'MBR, e dovrai reinstallare il boot manager precedente. Boot Easy può essere reinstallato usando - l'utility BOOTINST.EXE inclusa nella directory \TOOLS sul cdrom, oppure + l'utility BOOTINST.EXE inclusa nella directory + \TOOLS sul cdrom, oppure via ftp. Puoi anche ricominciare l'installazione e andare all'editor delle partizioni. Da lì, marcare la partizione di FreeBSD come avviabile, scegliere Boot Manager, e quindi digitare W per scrivere le informazioni nell'MBR. Puoi ora riavviare, e Boot Easy dovrebbe riconoscere Windows 95 e DOS. Ricordati che OS/2 può leggere partizioni FAT e HPFS, ma non FFS (FreeBSD) o EXT2 (Linux). Diversamente Windows 95 può leggere e scrivere solo su FAT o FAT32 (guarda la ). - FreeBSD può leggere gran parte degli altri filesystem, ma al + FreeBSD può leggere gran parte degli altri file system, ma al momento non può leggere partizioni HPFS. Linux può leggere partizioni HPFS, ma non può scrivervi. Versioni recenti del kernel di Linux (2.x) possono leggere e scrivere su partizioni di Windows 95 di tipo VFAT (VFAT è ciò che permette a Windows 95 di avere i nomi di file lunghi - è molto simile alla FAT). - Linux può leggere e scrivere sulla maggior parte dei filesystem. + Linux può leggere e scrivere sulla maggior parte dei file system. Capito? Lo spero... Esempi (La sezione ha bisogno di lavoro, per favore spedisci il tuo esempio a jayrich@sysc.com). FreeBSD+Win95: Se hai installato FreeBSD dopo Windows 95, dovresti vedere DOS nel menu di Boot Easy. Questo è Windows 95. Se hai installato Windows 95 dopo FreeBSD, leggi la sopra. Fin quando il tuo hard disk non ha più di 1024 cilindri, non dovrebbero esserci problemi. Se una partizione va oltre il 1024esimo cilindro, e hai messaggi di errore come invalid system disk sotto DOS (Windows 95) e FreeBSD non parte, prova a cercare una opzione nel BIOS chiamata > 1024 cylinder support o NORMAL/LBA mode. DOS potrebbe necessitare dell'LBA (Logical Block Addressing - Indirizzamento Logico dei Blocchi) per partire correttamente. Se l'idea di cambiare delle impostazioni nel BIOS ogni volta che si accende il computer non ti piace, puoi far partire FreeBSD da DOS con l'utility FBSDBOOT.EXE che trovi sul CD (dovrebbe trovare la tua partizione FreeBSD e farla partire). FreeBSD+OS/2+Win95: Nulla di nuovo qui. Il boot manager di OS/2 può far partire tutti questi sistemi operativi, cosicché non dovrebbero esserci problemi. FreeBSD+Linux: Puoi usare Boot Easy per far partire tutti e due i sistemi operativi. FreeBSD+Linux+Win95: (guarda la ) Altre Fonti di Aiuto Ci sono molti HOW-TO su Linux che trattano come affrontare il problema di avere più sistemi operativi sullo stesso hard disk. Il Linux+DOS+Win95+OS2 mini-HOWTO offre aiuto su come configurare il boot manager di OS/2 e il Linux+FreeBSD mini-HOWTO potrebbe essere anch'esso interessante. Anche il Linux-HOWTO è di grande aiuto. E il pacchetto di Hale Landis, How It Works contiene alcune utili informazioni su tutti i tipi di geometrie dei drive e su argomenti legati al processo di avvio. Puoi trovarlo su ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/allhiw.zip. Inoltre non perderti la documentazione del kernel di FreeBSD sul processo di avvio, disponibile nella distribuzione dei sorgenti del kernel (si scompatta in file:/usr/src/sys/i386/boot/biosboot/README.386BSD. Dettagli Tecnici (Contributo di Randall Hopper, rhh@ct.picker.com) Questa sezione prova a fornire abbastanza informazioni di base sugli hard disk e sul processo di avvio così da essere poi capaci di determinare le cause dei problemi più frequenti che potreste affrontare al momento dell'installazione e della configurazione di più sistemi operativi. Inizia con un linguaggio semplice, così potresti voler scorrere la pagina fino a quando non ti sembri difficile e cominciare quindi da quel punto a leggere. Introduzione agli Hard Disk Sono generalmente usati tre termini fondamentali per descrivere l'allocazione dei dati sull'hard disk: Cylinders (Cilindri), Heads (Testine), e Sectors (Settori). Non è particolarmente importante sapere esattamente cosa significano questi termini e quale sia il loro compito specifico, ma interessa sapere che, insieme, identificano dove si trovano fisicamente i dati sull'hard disk. Ogni hard disk ha un particolare numero di cilindri, di testine, e di settori per ogni parte di cilindro relativa a una singola testina (che generalmente viene chiamato track, o traccia). Questi dati contribuiscono a determinare la geometria fisica del disco dell'hard disk. Ci sono generalmente 512 byte per settore, e 63 settori per traccia, mentre il numero di cilindri e testine varia a seconda del tipo di hard disk. In questo modo puoi trovare la quantità di dati che il disco potrebbe contenere semplicemente calcolando: (numero di cilindri) × (numero di testine) × (63 settori/traccia) × (512 byte/settore) Per esempio, sul mio Western Digital AC31600 EIDE, questo è: (3148 cilindri) × (16 testine) × (63 settori/traccia) × (512 byte/settore) che sarebbe 1,624,670,208 byte, o circa 1.6 Giga. Puoi scoprire la geometria fisica del disco (cioè il numero di cilindri, testine, e il fattore settori/tracciati) del tuo hard disk usando ATAID o altri programmi reperibili su Internet. Probabilmente il tuo hard disk ti è stato venduto con queste informazioni. Comunque stai attento: se stai usando l'opzione LBA del BIOS (vedi la ), non puoi usare un qualsiasi programma per conoscere la geometria fisica. Questo perché molti programmi (ad esempio MSD.EXE o l'fdisk di FreeBSD) non identificano la geometria fisica del disco, fanno invece riferimento alla geometria traslata (Numeri virtuali usando LBA). Continua a leggere per saperne di più. Un altro aspetto interessante di questi termini. Dati 3 numeri—un numero di cilindri, un numero di testine, e un numero di settori per tracciato—si può identificare uno specifico settore assoluto (un blocco di 512 byte di dati) sull'hard disk. I cilindri e le testine sono numerati partendo da 0, e i settori sono numerati partendo da 1. Per quelli che sono interessati a dettagli più tecnici, informazioni sulla geometria dei dischi, settori di avvio, BIOS, e altro, possono trovare grandi quantità di informazioni in Internet. Basta fare una ricerca con Lycos, Yahoo e altri digitando boot sector o master boot record. Tra le numerose informazioni utili che si possono trovare c'è il pacchetto di documentazione How It Works (in italiano Come Funziona) di Hale Landis. Guarda la per alcuni puntatori a questo pacchetto. Ok, troppa terminologia finora. Adesso parliamo del processo di avvio. Il Processo di Avvio Sul primo settore del tuo disco (Cyl 0, Head 0, Sector 1) risiede il Master Boot Record (MBR). Questo contiene una mappa del tuo disco. Identifica fino a 4 partizioni, ciascuna delle quali è uno spazio, una parte, di quel disco. FreeBSD chiama queste partizioni slices per evitare confusione con le sue partizioni, di cui ora non parleremo. Ciascuna partizione può contenere un sistema operativo diverso. Ogni elemento che rappresenta una partizione presente nell'MBR ha un Partition ID, un valore Start Cylinder/Head/Sector, e un valore End Cylinder/Head/Sector. Il Partition ID mostra di che tipo di partizione si tratta (di che sistema operativo) e i valori di inizio/fine dicono dove questa si trova. La mostra una lista di partition ID più comuni. Partition ID ID (hex) Descrizione 01 DOS12 primaria (12-bit FAT) 04 DOS16 primaria (16-bit FAT) 05 DOS estesa 06 DOS primaria di grande dimensione (> 32MB) 0A OS/2 83 Linux (EXT2FS) A5 FreeBSD, NetBSD, 386BSD (UFS)
Nota che non tutte le partizioni sono avviabili (per esempio quelle DOS estese). Alcune lo sono, altre no. Ciò che rende una partizione avviabile è la configurazione del Partition Boot Sector che si trova all'inizio di ciascuna partizione. Quando configuri il tuo boot manager preferito, questo cerca gli elementi nella tavola delle partizioni sull'MBR di tutti i tuoi hard disk e fa in modo che tu possa dare un nome a tutte gli elementi della lista. Quindi all'avvio, il boot manager viene invocato da un codice particolare presente nell'MBR del primo hard disk che viene rilevato sul tuo sistema. Questo guarda la tavola delle partizioni dell'MBR corrispondente alla partizione che hai scelto, usa l'informazione sullo Start Cylinder/Head/Sector per quella partizione, carica il Partition Boot Sector per quella partizione, e sli dà il controllo. Quel settore di avvio per la partizione contiene abbastanza informazioni per cominciare a caricare il sistema operativo di quella partizione. Un particolare che abbiamo sorvolato e che è importante conoscere. Tutti gli hard disk hanno l'MBR. Ad ogni modo, quello importante è quello del disco che viene rilevato per primo dal BIOS. Se hai solo hard disk IDE, è il primo disco IDE (cioè il disco primario del controller primario). Stessa cosa per i sistemi SCSI. Se hai sia SCSI che IDE invece, i dischi IDE vengono riconosciuti per primi dal BIOS, quindi il primo disco IDE è quello che viene riconosciuto per primo. Il boot manager che installerai si troverà quindi sull'MBR del primo disco riconosciuto come descritto. Limitazioni sull'Avvio e Avvertimenti Ora un po' di cose interessanti alle quali devi stare attento. Il maledetto limite dei 1024 cilindri e l'aiuto dell'LBA del BIOS La prima parte del processo di avvio viene effettuata attraverso il BIOS, (se questo è un termine nuovo per te, il BIOS è un chip contenente del software presente sulla scheda madre che contiene il codice di avviamento per il computer). Quindi, questa prima parte del processo è soggetta alle limitazioni dell'interfaccia del BIOS. L'interfaccia BIOS usata per leggere gli hard disk in questo momento (INT 13H, Subfunction 2) alloca 10 bit per il Cylinder Number, 8 bit per l'Head Number, e 6 bit per il Sector Number. Questo porta gli utenti ad essere sottoposti a dei limiti (per esempio i boot manager installati nell'MBR così come i loader installati nei Boot Sector) che ora vediamo: 1024 cilindri, massimo 256 testine, massimo 64 settori/traccia, massimo (in realtà 63, 0 non è disponibile) Ora, hard disk grossi hanno molti cilindri, ma non molte testine, quindi invariabilmente con grandi hard disk il numero di cilindri sarà più alto di 1024. A causa di questo e della situazione dell'interfaccia BIOS, non puoi far partire un sistema operativo da qualsiasi punto del disco. Il codice di avvio (il boot manager e il loader del sistema operativo devono essere nei settori di avvio di tutte le partizioni avviabili) deve risiedere entro il limite dei 1024 cilindri. In pratica, se il tuo hard disk è generico e contiene 16 testine, questo si tramuta in: 1024 cilindri/disco × 16 testine/disco × 63 settori/traccia × 512 byte/settore che è intorno al summenzionato limite dei 528MB. Qui è dove entra in gioco l'LBA (Logical Block Addressing, Indirizzamento Logico dei Blocchi) del BIOS. L'LBA del BIOS fornisce all'utente delle API del BIOS accesso ai cilindri fisici oltre al 1024esimo attraverso l'interfaccia BIOS ridefinendo un cilindro. Quindi, rimappa cilindri e testine, facendo sembrare al BIOS che il computer contenga meno cilindri e più testine di quanto in realtà non ne abbia. In altre parole, si avvantaggia del fatto che gli hard disk hanno relativamente poche testine e molti cilindri semplicemente bilanciando tra cilindri e testine facendo in modo che tutti e due i numeri rimangano sotto la soglia (1024 cilindri, 256 testine). Con l'LBA del BIOS, la limitazione agli hard disk è virtualmente eliminata (beh, spostata ad 8 Gigabyte). Se hai un BIOS che supporta l'LBA, puoi mettere FreeBSD o qualsiasi altro OS in qualsiasi parte tu voglia senza toccare il limite dei 1024 cilindri. Per usare ancora l'esempio del mio Western Digital da 1.6 Giga, la sua geometria fisica è: (3148 cilindri, 16 testine, 63 settori/traccia, 512 byte/settore) Ad ogni modo, il mio LBA del BIOS rimappa questo in: (787 cilindri, 64 testine, 63 settori/traccia, 512 byte/settore) dandomi la stessa grandezza effettiva di disco, ma con numero di cilindri e testine entro i limiti dell'API del BIOS (casualmente, ho sia Linux che FreeBSD installati su uno dei miei hard disk sopra il 1024esimo cilindro fisico, e tutti e due partono perfettamente, grazie all'LBA del BIOS). Boot Manager e Allocazione del Disco Un altro punto di cui tener conto al momento al momento dell'installazione di un boot manager, è quello di ricordarsi di allocare spazio per il tuo boot manager. È meglio aver presente fin da subito questo problema, per non accorgersene troppo tardi e dover quindi reinstallare uno o più sistemi operativi. Se hai seguito il discorso nella a proposito del Master Boot Sector (dove si trova l'MBR), dei Partition Boot Sectors, e dell processo di avvio, potresti esserti chiesto esattamente dove quel piccolo boot manager risiede sul tuo hard disk. Bene, alcuni boot manager sono abbastanza piccoli da risiedere nel Master Boot Sector (Cilindro 0, Testina 0, Settore 0) insieme alla tabella delle partizioni. Alcuni invece hanno bisogno di un po' di spazio in più e si estendono su alcuni settori oltre il Master Boot Sector nella traccia del Cilindro 0 Testina 0, dato che questa è tipicamente libera. Ecco qui. Alcuni sistemi operativi (incluso FreeBSD) fanno in modo che le loro partizioni possano cominciare subito dopo il Master Boot Sector, cioè al cilindro 0, testina 0, settore 2 se vuoi. Infatti, se dai al sysinstall di FreeBSD un disco con una parte iniziale vuota oppure un disco vuoto, quello è il punto da cui comincerà la partizione FreeBSD di default (o almeno lo ha fatto quando sono caduto in questa trappola). Poi quando vai ad installare il tuo boot manager, se è uno che occupa alcuni settori oltre all'MBR, andrà a sovrascrivere la parte iniziale dei dati della prima partizione. Nel caso di FreeBSD, questo sovrascrive il label del disco, e fa in modo da rendere non avviabile la partizione di FreeBSD. Il modo più semplice per eliminare questo problema (e lasciarti la flessibilità di provare in seguito differenti boot manager) è quello di lasciare sempre la prima traccia del tuo hard disk completamente libera quando partizioni il tuo hard disk. Ciò significa lasciare libero lo spazio tra il cilindro 0, testina 0, settore 2 fino a cilindro 0, testina 0, settore 63, e cominciare la prima partizione sul cilindro 0, testina 1, settore 1. Per ciò che vale, quando crei una partizione DOS all'inizio del tuo hard disk, il DOS lascia sempre questo spazio libero di default (ecco perché molti boot manager presumono che sia libero). Quindi creare una partizione DOS all'inizio del disco toglie questi problemi tutti insieme. Mi piace fare da solo, creando una partizione DOS da 1 mega all'inizio, perché questo evita che cambino le lettere dei drive DOS quando ripartiziono in seguito. Come riferimento, i seguenti boot manager usano il Master Boot Sector per immagazzinare il loro codice e i loro dati: OS-BS 1.35 Boot Easy LILO Questi boot manager usano alcuni settori addizionali dopo il Master Boot Sector: OS-BS 2.0 Beta 8 (settori 2-5) Boot Manager di OS/2 Cosa fare se il tuo computer non parte? In alcuni momenti quando installi dei boot manager, potresti lasciare l'MBR in uno stato in cui il computer non riesce più a partire. Questo è spiacevole, ma possibile quando si utilizza FDISK su di un boot manager già installato. Se hai una partizione DOS avviabile sul tuo hard disk, puoi partire da un floppy DOS, e poi eseguire il comando: A:\> FDISK /MBR Per mettere il codice originale di avvio del DOS nel sistema. Puoi ora avviare DOS (e solamente DOS) dall'hard disk. Alternativamente, puoi far ripartire il programma di installazione del tuo boot manager da un floppy avviabile.
diff --git a/it_IT.ISO8859-15/articles/new-users/article.sgml b/it_IT.ISO8859-15/articles/new-users/article.sgml index 6c41e5e620..18b78bc678 100644 --- a/it_IT.ISO8859-15/articles/new-users/article.sgml +++ b/it_IT.ISO8859-15/articles/new-users/article.sgml @@ -1,1069 +1,1069 @@ %man; %mailing-lists; %translators; ]>
Per chi è alle Prime Armi sia con FreeBSD che con Unix Annelise Anderson
andrsn@andrsn.stanford.edu
 15 Agosto 1997 Congratulazioni per aver installato FreeBSD! Questa introduzione é per chi é alle prime armi con FreeBSD e Un*x—perciò comincia dalle basi. Stai certamente usando la versione 2.0.5 o una più recente di FreeBSD distribuita da BSDi o FreeBSD.org, il tuo sistema ha (per il momento) un solo utente (te stesso)—e sei probabilmente abbastanza bravo con DOS/WINDOWS o OS/2. Traduzione a cura di &a.it.max;. Entrare ed Uscire dal Sistema Entra (quando vedi login:) come l'utente che hai creato durante l'installazione oppure come root. (La tua installazione di FreeBSD dovrebbe già avere un account di root; root può andare ovunque e fare qualsiasi cosa, anche cancellare file essenziali, perciò stai attento!) I simboli &prompt.user; e &prompt.root; che incontrerai più avanti simboleggiano il prompt (i tuoi potrebbero essere differenti), dove &prompt.user; indica un utente ordinario e &prompt.root; indica root. Per uscire (e ritrovarsi con un nuovo prompt login:) scrivi &prompt.root; exit tante volte quanto serve. Sì, premi invio dopo ogni comando, e ricordati che Unix fa distinzione tra maiuscole e minuscole—perciò exit, non EXIT. Per spegnere il computer digita &prompt.root; /sbin/shutdown -h now O per riavviarlo digita &prompt.root; /sbin/shutdown -r now oppure &prompt.root; /sbin/reboot Puoi anche riavviarlo premendo CtrlAltCanc. Lasciagli un po' di tempo per compiere il suo lavoro. Questo equivale a /sbin/reboot nelle versioni più recenti di FreeBSD ed è molto meglio che premere il bottone di reset. Non vorrai mica reinstallare tutto da capo, vero? Aggiungere un Utente con Privilegi di Root Se non hai creato un utente durante l'installazione e quindi sei entrato nel sistema come root, dovresti probabilmente crearne uno ora tramite &prompt.root; adduser La prima volta che aggiungi un utente, il sistema dovrebbe chiederti di inserire delle impostazioni di default da applicare. Potresti volere come shell &man.csh.1; invece di &man.sh.1;, se ti viene consigliato sh come default. Altrimenti premi solo invio per accettare i valori proposti. Questi dati vengono salvati in /etc/adduser.conf, un file modificabile successivamente a mano. Supponiamo che tu voglia creare l'utente jack di nome reale Jack Benimble. Assegna a jack una password per ragioni di sicurezza (anche i bambini che gironzolano per casa potrebbero mettere le mani sulla tastiera). Quando ti viene chiesto se vuoi invitare jack in un altro gruppo, digita wheel Login group is ``jack''. Invite jack into other groups: wheel Questo ti permetterà di entrare come l'utente jack e usare il comando &man.su.1; per diventare root. A quel punto non sarai più preso in giro per essere entrato direttamente come root. Puoi uscire da adduser in qualsiasi momento premendo CtrlC, e alla fine avrai l'opportunità di approvare il nuovo utente oppure premere n per non farlo. Potresti voler creare un secondo utente (jill?) cosicché quando andrai a modificare i file di jack avrai un'ancora di salvezza in caso qualcosa vada male. Una volta fatto questo, usa exit per tornare al prompt di login ed entrare come jack. In generale è meglio cercare di lavorare da utente normale in modo da non avere il potere—e il rischio—di root. Se hai già creato un utente e vuoi che quell'utente sia in grado di usare su per diventare root, puoi entrare come root e modificare il file /etc/group, aggiungendo jack alla prima linea (il gruppo wheel). Ma prima devi fare pratica con &man.vi.1;, l'editor di testo—oppure usa il più semplice &man.ee.1;, installato sulle recenti versioni di FreeBSD. Per cancellare un utente, usa il comando rmuser. Diamoci un'occhiata in giro Una volta avuto accesso come utente normale, guardati in giro e prova alcuni dei comandi che ti daranno accesso alle fonti di aiuto e di informazioni su FreeBSD. Ecco qui una lista di comandi e le loro funzioni: id Ti dice chi sei! pwd Ti mostra dove sei—la directory in cui stai lavorando. ls Ti mostra una lista dei file contenuti nella directory. ls Ti mostra un elenco dei file contenuti nella directory ponendo * dopo i file eseguibili, / dopo le directory, e @ dopo i collegamenti simbolici. ls Mostra un elenco di file nel formato lungo—grandezza, data, permessi. ls Mostra una lista dei file nascosti, cioè con un punto davanti al nome, insieme agli altri. Se sei root, i file puntati vengono mostrati anche senza l'opzione . cd Cambia la directory di lavoro. cd .. torna alla directory superiore; nota lo spazio dopo cd. cd /usr/local va nella directory specificata. cd ~ va nella directory home dell'utente collegato in quel momento—per esempio, /usr/home/jack. Prova cd /cdrom, e poi ls, per scoprire se il tuo CDROM è montato e funziona. view nomefile Mostra il contenuto del file (chiamato nomefile) senza modificarlo. Prova view /etc/fstab. :q per uscire. cat nomefile Mostra nomefile sullo schermo. Se è troppo lungo e ne puoi vedere solo la fine, premi BlocScorr e usa freccia-su per muoverti in alto; puoi usare BlocScorr anche con le pagine man. Premi ancora BlocScorr per uscire dallo scorrimento. Potresti provare cat con alcuni dei file nascosti presenti nella tua directory home—cat .cshrc, cat .login, cat .profile. Noterai degli alias in .cshrc per alcuni dei comandi ls (sono molto convenienti). Puoi creare degli altri alias modificando .cshrc. Puoi far sì che questi alias diventino disponibili a tutti gli utenti mettendoli nel file di configurazione generale di csh, /etc/csh.cshrc. Ottenere Aiuto e Informazioni Ecco alcune risorse utili per ottenere aiuto. Testo è qualcosa che puoi digitare a tuo piacere—normalmente si tratta di un comando o del nome di un file. apropos testo Tutto ciò che contiene la stringa testo nel database whatis. man testo Mostra la pagina man di testo, la maggior risorsa di documentazione per i sistemi Un*x. man ls ti dirà tutti i modi possibili per usare il comando ls. Premi Invio per muoverti nel testo, CtrlB per andare indietro di una pagina, CtrlF per andare avanti, q oppure CtrlC per uscire. which testo Ti dice dove si trova il comando testo nel path dell'utente. locate testo Ti dice tutte le directory nei path dell'utente in cui si trova il comando testo. whatis testo Ti dice che cosa fa il comando testo e la sua pagina man. Digitando whatis * ti verranno presentate tutte le pagine man associate agli eseguibili presenti nella directory corrente. whereis testo Trova il file testo, dandoti il suo percorso completo. Potresti voler provare ad usare whatis con alcuni comandi utili come cat, more, grep, mv, find, tar, chmod, chown, date, e script. more ti permette di leggere una pagina alla volta come in DOS, ad esempio, ls -l | more oppure more nomefile. * ha valore assoluto—per esempio, ls w* mostra tutti i file che cominciano con w. Per caso alcuni di questi comandi non funzionano correttamente? Sia &man.locate.1;, sia &man.whatis.1; dipendono da un database che viene ricostruito settimanalmente. Se la tua macchina non sarà lasciata accesa per il fine settimana (usando FreeBSD), può darsi che tu voglia usare i comandi per la manutenzione giornaliera, settimanale, e mensile ogni tanto. Falli partire come root e lascia loro il tempo di finire il lavoro prima di farne partire un altro. &prompt.root; periodic daily output tralasciato &prompt.root; periodic weekly output tralasciato &prompt.root; periodic monthly output tralasciato Se ti stufi di aspettare, premi AltF2 per avere un'altra console virtuale, e poterti loggare nuovamente. Dopotutto è un sistema multi-utente, e multi-tasking. Probabilmente questi comandi produrranno dei messaggi sullo schermo quando lavorano; puoi digitare clear per pulire lo schermo. Quando hanno finito, dovresti dare un'occhiata a /var/mail/root e /var/log/messages. Usare tali comandi fa parte dell'amministrazione di sistema—e come utente singolo di un sistema Unix, sei tu l'amministratore del sistema. Praticamente l'unica cosa per la quale è necessario che tu sia root è l'amministrazione. Queste responsabilità non vengono trattate bene nemmeno in quei grossi libri su Unix, che sembrano dedicare troppo spazio all'uso dei menu nei windows manager. Potresti voler leggere uno dei più interessanti libri sull'amministrazione di sistema, come UNIX System Administration Handbook di Evi Nemeth et.al. (Prentice-Hall, 1995, ISBN 0-13-15051-7)—la seconda edizione con la copertina rossa; oppure Essential System Administration di Æleen Frisch (O'Reilly & Associates, 1993, ISBN 0-937175-80-3). Io ho usato quello di Nemeth. Modificare File di Testo Per poter configurare il tuo sistema, devi modificare dei file. Molti di questi saranno in /etc; e avrai bisogno del comando su per diventare root e poter così modificarli. Puoi usare il semplice editor ee, ma alla lunga risulta più utile imparare vi. C'é un eccellente tutorial su vi in /usr/src/contrib/nvi/docs/tutorial se lo hai installato; altrimenti puoi scaricarlo via FTP da ftp.cdrom.com dalla directory FreeBSD/FreeBSD-current/src/contrib/nvi/docs/tutorial. Prima di modificare un file, dovresti farne una copia. Supponiamo tu voglia modificare /etc/rc.conf. Puoi semplicemente usare cd /etc per andare in /etc e fare: &prompt.root; cp rc.conf rc.conf.orig Questo copierà rc.conf in rc.conf.orig, e potrai successivamente copiare rc.conf.orig in rc.conf per tornare all'originale. Ma ancora meglio sarà spostare (rinominare) il file per poi ricopiarlo con il nome originale: &prompt.root; mv rc.conf rc.conf.orig &prompt.root; cp rc.conf.orig rc.conf perché il comando mv mantiene la data e il proprietario originali del file. Puoi ora modificare rc.conf. Se vuoi tornare all'originale, potresti fare mv rc.conf rc.conf.myedit (assumendo che vuoi tenere la versione modificata) e quindi fare &prompt.root; mv rc.conf.orig rc.conf per tornare allo stato iniziale. Per modificare un file, digita &prompt.root; vi nomefile Muoviti nel testo con i tasti freccia. Esc mette vi in modalità comando. Ecco qui alcuni dei comandi: x cancella la lettera su cui si trova il cursore dd cancella l'intera riga (anche se va a capo sullo schermo) i inserisci del testo nella posizione del cursore a inserisci del testo dopo il cursore Quando digiti i o a, puoi inserire del testo. Esc ti riporta in modalità comando dove puoi digitare :w per salvare le modifiche sul disco e continuare a modificare il file :wq per salvare le modifiche e uscire :q! per uscire senza salvare le modifiche /testo per spostare il cursore su testo; /Invio per trovare la prossima occorrenza di testo. G per andare alla fine del file nG per andare alla riga n del file, dove n è un numero CtrlL per ridisegnare lo schermo Ctrlb e Ctrlf vai avanti e indietro di una pagina, come succede con more e view. Fai un po' di pratica con vi nella tua directory home creando un nuovo file digitando vi nomefile e aggiungendo e cancellando del testo, salvando il file, e riaprendolo di nuovo. vi è pieno di sorprese perché è abbastanza complesso, e ti capiterà di digitare un comando che farà di sicuro qualcosa che non ti aspetti. (Alcune persone preferiscono vi—è più potente dell'EDIT del DOS—scopri il comando :r) Usa Esc una o più volte per essere sicuro di essere in modalità comando e continua da lì quando hai dei problemi, salva spesso con :w, e usa :q! per uscire e ricominciare (dal tuo ultimo :w) quando ne hai bisogno. Ora puoi usare cd per andare in /etc, su per diventare root, vi per modificare il file /etc/group, e aggiungere un utente al gruppo wheel cosicché possa avere privilegi di root. Aggiungi solo una virgola e il nome di login dell'utente alla fine della prima riga del file, premi Esc, e usa :wq per salvare il file su disco e uscire. La modifica ha effetto immediato. (Non hai lasciato uno spazio dopo la virgola, vero?) Stampa di File da DOS A questo punto la tua stampante non funzionerà ancora sotto FreeBSD, ecco quindi un sistema per creare un file da una pagina man, metterlo su un floppy, e quindi stamparlo da DOS. Supponiamo che tu voglia leggere attentamente come cambiare i permessi sui file (abbastanza importante). Puoi usare man chmod per leggere come fare. Il comando &prompt.user; man chmod | col -b > chmod.txt toglierà gli elementi di formattazione e manderà il tutto sul file chmod.txt al posto di mostrare il contenuto sullo schermo. Ora metti un dischetto formattato DOS nel lettore, digita su per diventare root, e scrivi &prompt.root; /sbin/mount -t msdos /dev/fd0 /mnt per montare il floppy su /mnt. Ora (non hai più bisogno di essere root, e puoi digitare exit per tornare ad essere l'utente jack) puoi andare nella directory in cui hai creato chmod.txt e copiare il file sul floppy digitando: &prompt.user; cp chmod.txt /mnt e usare ls /mnt per vedere il contenuto di /mnt, che dovrebbe contenere il file chmod.txt. In particolare potresti voler creare un file con l'output di /sbin/dmesg digitando &prompt.user; /sbin/dmesg > dmesg.txt e copiare dmesg.txt sul floppy. /sbin/dmesg è il file di log di avvio, ed è importante comprenderlo perché ti mostra cosa ha trovato FreeBSD all'avvio. Se poni delle domande sulla &a.questions; o su un gruppo USENET—del tipo FreeBSD non trova il mio drive per i nastri, che cosa faccio?—la gente vorrà sapere cosa mostra il tuo dmesg. Ora devi smontare il floppy (da root) per poter togliere il disco &prompt.root; /sbin/umount /mnt e riavviare per tornare in DOS. Copia questo file in una directory DOS, richiamali con l'EDIT del DOS, Notepad o Wordpad di Windows, o un editor di testi, fai una piccola modifica in modo che il file debba essere salvato, e stampa come faresti da DOS o Windows. Spera che funzioni! Le pagine man vengono meglio se stampate con il comando DOS print. (Copiare i file da FreeBSD su una partizione DOS montata è ancora in alcuni casi rischioso.) Far funzionare la stampante sotto FreeBSD consiste nel creare un opportuno elemento in /etc/printcap e creare una directory di spool corrispondente in /var/spool/output. Se la tua stampante è su lpt0 (ciò che DOS chiama LPT1), devi solo andare in /var/spool/output e (da root) creare la directory lpd digitando: mkdir lpd, se non è già presente. A quel punto la stampante dovrebbe rispondere quando il sistema parte, e lp o lpr dovrebbero mandare un file alla stampante. Che il file venga stampato o meno è solo questione di configurazione, che è discussa nel Manuale di FreeBSD. Altri Comandi Utili df mostra lo spazio disponibile e tutte le partizioni montate. ps aux mostra i processi in esecuzione. ps ax è una forma contratta. rm nomefile cancella nomefile. rm -R dir cancella la directory dir e tutte le sottodirectory—attenzione! ls -R mostra il contenuto della directory e delle sue sottodirectory; io usavo una variante, ls -AFR > where.txt, per avere una lista dei file in / e (separatamente) /usr prima che scoprissi dei metodi migliori per cercare i file. passwd per cambiare la password dell'utente (o di root) man hier - pagina man sul filesystem di Unix + pagina man sul file system di Unix Usa find per trovare nomefile in /usr o nelle sue sottodirectory digitando &prompt.user; find /usr -name "nomefile" Puoi usare * come identificatore universale in "nomefile" (che dovrebbe essere tra virgolette). Se dici a find di cercare in / anziché /usr cercherà il/i file su - tutti i filesystem montati, inclusi i CDROM e le partizioni DOS. + tutti i file system montati, inclusi i CDROM e le partizioni DOS. Un libro eccellente che tratta i comandi e le utility di Unix è Unix for the Impatient di Abrahams & Larson (2nd ed., Addison-Wesley, 1996). Ci sono anche un sacco di informazioni su Unix su Internet. Guarda Unix Reference Desk. Prossimi Passi Dovresti ora avere gli strumenti necessari per girare nel sistema e modificare i file, così da poter rendere tutto funzionante. Ci sono un sacco di informazioni nel Manuale di FreeBSD (che è probabilmente sul tuo disco rigido) e sul sito web di FreeBSD. Una grande scelta di package e port è presente sul CDROM così come sul sito web. Il manuale ti spiega come usarli (prendi il package se esiste, con pkg_add /cdrom/packages/All/nomepackage, dove nomepackage è il nome del file del package). Il CDROM ha una lista di package e di port con delle brevi descrizioni in cdrom/packages/index, cdrom/packages/index.txt, e cdrom/ports/index, e con descrizioni più ampie in /cdrom/ports/*/*/pkg/DESCR, dove * rappresenta rispettivamente sottodirectory di tipi di programmi e nomi di programmi. Se trovi il manuale troppo difficile su come installare i port dal CDROM (con il sistema di lndir e altro), ecco come funziona normalmente: Trova il port che vuoi, supponiamo kermit. Ci sarà una directory per lui sul CDROM. Copia la sottodirectory in /usr/local (un buon posto perché il software che aggiungi sia disponibile a tutti gli utenti) con: &prompt.root; cp -R /cdrom/ports/comm/kermit /usr/local Questo dovrebbe portarti ad avere la sottodirectory /usr/local/kermit che contiene tutti i file presenti nella sottodirectory kermit del CDROM. Ora, crea la directory /usr/ports/distfiles se non esiste ancora, usando mkdir. Poi controlla /cdrom/ports/distfiles cercando un file con il nome che indica che si tratta del port esatto. Copia quel file in /usr/ports/distfiles; nelle versioni più recenti puoi saltare questo passo, perché FreeBSD lo farà per te. Nel caso di kermit, non c'è nessun distfile. Quindi entra con cd nella sottodirectory di /usr/local/kermit che contiene il file Makefile. Digita &prompt.root; make all install Durante questo processo il port userà FTP per scaricare i file compressi che non ha trovato sul CDROM o in /usr/ports/distfiles. Se la tua connessione non funziona ancora e non c'è nessun file per il port in /cdrom/ports/distfiles, dovrai recuperare il distfile usando un'altra macchina e poi copiarlo in /usr/ports/distfiles da un dischetto o dalla partizione DOS. Leggi Makefile (usando cat o more oppure view) per scoprire dove andare (il sito principale di distribuzione) per trovare il file e conoscere il suo nome. Il nome verrà troncato quando scaricato da DOS, e dopo averlo trasferito in /usr/ports/distfiles dovrai rinominarlo (usando il comando mv) nel suo nome originale cosicché possa essere trovato. (Usa il trasferimento di file binario!) Quindi torna in /usr/local/kermit, trova la directory contenente Makefile, e digita make all install. Un'altra cosa che può succedere quando si installa un port o un package è che questi abbiano bisogno di un altro programma. Se l'installazione si ferma con un messaggio can't find unzip o simile, potresti dover installare il package o il port di unzip prima di proseguire. Una volta installato, digita rehash per far sì che FreeBSD rilegga i file contenuti nel path e sappia quali sono presenti. (Se trovi un sacco di messaggi path not found quando usi whereis o which, dovresti fare delle aggiunte all'elenco delle directory nel file .cshrc nella tua directory home. L'elenco dei path in Unix fa la stessa cosa che fa in DOS, tranne che la directory corrente (di default) non si trova nel path per ragioni di sicurezza; se il comando che vuoi eseguire è nella directory in cui ti trovi, devi digitare ./ prima del nome del comando; niente spazio dopo la barra.) Potresti volere la versione più recente di Netscape dal loro sito FTP. (Netscape necessita dell'X Window System.) Ora c'é una versione per FreeBSD, quindi dà un'occhiata in giro. Usa solo gunzip nomefile e tar xvf nomefile sul file, sposta il binario in /usr/local/bin o qualche altro posto in cui vengono tenuti i binari, esegui rehash, e quindi aggiungi le seguenti linee a .cshrc in tutte le directory home degli utenti oppure (più semplicemente) in /etc/csh.cshrc, il file di configurazione globale di csh: setenv XKEYSYMDB /usr/X11R6/lib/X11/XKeysymDB setenv XNLSPATH /usr/X11R6/lib/X11/nls Questo assume che il file XKeysymDB e la directory nls siano in /usr/X11R6/lib/X11; se non lo sono, trovale e mettile lì. Se hai originariamente installato Netscape dal CDROM (o via FTP), non sostituire /usr/local/bin/netscape con il nuovo binario di netscape; questo è solo uno script di shell che imposta le variabili di ambiente per te. Rinomina invece il nuovo binario in netscape.bin e rimpiazza il vecchio binario, che dovrebbe essere /usr/local/netscape/netscape. Il tuo Ambiente di Lavoro La shell è la parte più importante del tuo ambiente di lavoro. In DOS, la shell è solitamente command.com. La shell è ciò che interpreta i comandi che digiti sulla linea di comando, e quindi comunica con il resto del sistema operativo. Puoi anche scrivere script di shell, che sono come i file batch di DOS: una serie di comandi che devono essere eseguiti senza il tuo intervento. Due shell vengono normalmente installate con FreeBSD: csh e sh. csh è buona per lavoro da linea di comando, ma gli script dovrebbero essere scritti usando sh (o bash). Puoi scoprire che shell hai digitando echo $SHELL. csh è una buona shell, ma tcsh fa tutto ciò che csh fa e anche altro. Ti permette di richiamare i comandi usando le frecce e ti permette di modificarli. Ha l'auto-completamento dei nomi di file con tab (csh usa Esc), e ti permette di tornare alla directory in cui eri digitando cd -. È anche più semplice alterare il prompt con tcsh. Ti rende la vita più facile. Ecco tre semplici passi per installare una nuova shell: Installa la shell tramite port o package, come faresti con un qualsiasi altro port o package. Usa rehash e which tcsh (assumendo che tu stia installando tcsh) per essere sicuro di averla installata. Da root, modifica /etc/shells, aggiungendo una riga nel file per la nuova shell, in questo caso /usr/local/bin/tcsh, e salva il file. (Alcuni port lo fanno per te.) Usa il comando chsh per cambiare permanentemente la tua shell in tcsh, o digita tcsh al prompt per cambiare la shell senza dover uscire dal sistema per poi rientrare. Può essere pericoloso cambiare la shell di root in qualcosa di diverso da sh o csh su versioni più recenti di FreeBSD e di Unix; potresti non avere una shell funzionante se il sistema entra in modalità singolo utente. La soluzione è usare su -m per diventare root, che ti dà tcsh come shell di root, poiché la shell è parte del tuo ambiente. Puoi rendere tutto ciò permanente aggiungendo al tuo .tcshrc un alias con alias su su -m. Quando tcsh parte, legge i file /etc/csh.cshrc e /etc/csh.login, come farebbe csh. Leggerà anche il file .login nella tua directory home ed anche .cshrc, a meno che tu non abbia un file .tcshrc. Puoi crearlo copiando .cshrc in .tcshrc. Ora che hai installato tcsh, puoi sistemare il tuo prompt. Puoi trovare i dettagli nella pagina man di tcsh, ma ecco qui una linea da mettere nel tuo .tcshrc che ti dirà quanti comandi hai digitato, che ore sono, e in che directory ti trovi. Produce anche un > se sei un utente normale e un # se sei root, ma tsch lo farebbe in ogni caso: set prompt = "%h %t %~ %# " Questa dovrebbe andare nella stessa posizione della linea di prompt corrente se ce n'è una, o sotto "if($?prompt) then" in caso contrario. Commenta la vecchia riga; così potrai tornare a quella vecchia se la preferirai. Non dimenticare gli spazi e le virgolette. Puoi far rileggere .tcshrc digitando source .tcshrc. Puoi avere una lista delle variabili di sistema che sono state impostate digitando env al prompt. Il risultato ti mostrerà il tuo editor di default, il pager, e il tipo di terminale, tra le altre possibili variabili. Un comando utile se ti connetti al sistema da una postazione remota e non riesci ad eseguire un programma perché il terminale non ne è capace è setenv TERM vt100. Altro Da root puoi smontare il CDROM con /sbin/umount /cdrom, toglilo dal lettore, inseriscine un altro, e montalo con /sbin/mount_cd9660 /dev/cd0a /cdrom assumendo che cd0a sia il nome di dispositivo del tuo lettore di CDROM. La versione più recente di FreeBSD ti permette di montare il CDROM solo con /sbin/mount /cdrom. - Usare il live filesystem—il secondo cd del set di - FreeBSD—è + Usare il live file system—il secondo cd del set + di FreeBSD—è utile se hai poco spazio a disposizione. Ciò che si trova - sul live filesystem cambia da release a release. Potresti + sul live file system cambia da release a release. Potresti provare ad eseguire dei giochi dal CDROM. Questo comporta l'uso di lndir, che viene installato con l'X Window System, per dire ai programmi dove trovare i file necessari, poiché - questi si trovano nel filesystem /cdrom + questi si trovano nel file system /cdrom anziché /usr e le sue sottodirectory, che è dove dovrebbero essere. Leggi man lndir per avere più informazioni. I Commenti sono Benvenuti Se usi questa guida, sarei interessata a sapere dove non è chiara, ciò che è stato tralasciato e che vorresti venisse incluso, e sapere se tutto ciò è stato utile. I miei ringraziamenti vanno a Eugene W. Stark, professore di informatica a SUNY-Stony Brook, e John Fieber per i suoi utili commenti. Annelise Anderson, andrsn@andrsn.stanford.edu Per questioni legate alla traduzione, o se avete commenti da poter esprimere solo in italiano, non esitate a contattarmi. Come per l'autrice originale, ogni genere di commenti è ben accetto. Massimiliano Stucchi, stucchi@willystudios.com
diff --git a/it_IT.ISO8859-15/share/sgml/freebsd.dsl b/it_IT.ISO8859-15/share/sgml/freebsd.dsl index a1aba88916..0aede93f80 100644 --- a/it_IT.ISO8859-15/share/sgml/freebsd.dsl +++ b/it_IT.ISO8859-15/share/sgml/freebsd.dsl @@ -1,92 +1,93 @@ ]> .") (make empty-element gi: "br") (literal "Per domande su questa documentazione, invia una e-mail a <") (create-link (list (list "HREF" "mailto:doc@FreeBSD.org")) (literal "doc@FreeBSD.org")) (literal ">."))))) (element quote (make sequence (literal "``") (process-children) (literal "''"))) (define %refentry-xref-link% #t) (define ($create-refentry-xref-link$ #!optional (n (current-node))) (let* ((r (select-elements (children n) (normalize "refentrytitle"))) (m (select-elements (children n) (normalize "manvolnum"))) (v (attribute-string (normalize "vendor") n)) (u (string-append "http://www.FreeBSD.org/cgi/man.cgi?query=" (data r) "&" "sektion=" (data m)))) (case v + (("current") (string-append u "&" "manpath=FreeBSD+5.0-current")) (("xfree86") (string-append u "&" "manpath=XFree86+4.2.0")) (("netbsd") (string-append u "&" "manpath=NetBSD+1.5")) (("ports") (string-append u "&" "manpath=FreeBSD+Ports")) (else u)))) ]]> (define (local-it-label-title-sep) (list (list (normalize "warning") ": ") (list (normalize "caution") ": ") (list (normalize "chapter") " ") (list (normalize "sect1") " ") (list (normalize "sect2") " ") (list (normalize "sect3") " ") (list (normalize "sect4") " ") (list (normalize "sect5") " ") )) diff --git a/it_IT.ISO8859-15/share/sgml/legalnotice.sgml b/it_IT.ISO8859-15/share/sgml/legalnotice.sgml index 710ca10ce2..75d760a813 100644 --- a/it_IT.ISO8859-15/share/sgml/legalnotice.sgml +++ b/it_IT.ISO8859-15/share/sgml/legalnotice.sgml @@ -1,47 +1,47 @@ - + La ridistribuzione e l'uso come sorgente (SGML DocBook) e in forme 'compilate' (SGML, HTML, PDF, PostScript, RTF e cosí via) con o senza modifiche, sono permessi a patto che le seguenti condizioni vengano rispettate: Le ridistribuzioni del codice sorgente (SGML DocBook) devono mantenere le suddette note sul copyright, questa lista di condizioni e il seguente avviso, non modificati, come prime linee di questo file. Le ridistribuzioni in forma compilata (trasformazioni in altri DTD, conversioni in PDF, PostScript, RTF e altri formati) devono riportare le suddette note di copyright, questa lista di condizioni e il seguente avviso nella documentazione e/o in altri materiali forniti con la distribuzione. QUESTA DOCUMENTAZIONE È FORNITA DAL FREEBSD ITALIAN DOCUMENTATION PROJECT "COSÌ COM'È" E NON VIENE RICONOSCIUTA NESSUNA GARANZIA ESPLICITA O IMPLICITA, INCLUSE, MA NON SOLO, LE GARANZIE IMPLICITE DI COMMERCIABILITÀ E IDONEITÀ PER UNO SCOPO PARTICOLARE. IN NESSUN CASO IL FREEBSD ITALIAN DOCUMENTATION PROJECT POTRÀ ESSERE RITENUTO RESPONSABILE DI QUALSIASI DANNO DIRETTO, INDIRETTO, ACCIDENTALE, SPECIALE, SIMBOLICO, O CONSEGUENTE (INCLUSI, MA NON SOLO, L'ACQUISIZIONE DI BENI O SERVIZI SOSTITUTIVI; LA PERDITA D'USABILITÀ, DI DATI O DI PROFITTI; O L'INTERRUZIONE DEL LAVORO) COMUNQUE CAUSATO E SULLA BASE DI QUALUNQUE TEORIA DI RESPONSABILITÀ, SIA CONTRATTUALE, SIA OGGETTIVA, SIA FONDATA SULL'ILLECITO CIVILE (INCLUSA NEGLIGENZA O QUANT'ALTRO) DERIVANTE IN OGNI MODO DALL'USO DI QUESTA DOCUMENTAZIONE, ANCHE SE AVVISATO DELLA POSSIBILITÀ DI DETTO DANNO. diff --git a/it_IT.ISO8859-15/share/sgml/mailing-lists.ent b/it_IT.ISO8859-15/share/sgml/mailing-lists.ent index 047f524074..93b8fd7c50 100644 --- a/it_IT.ISO8859-15/share/sgml/mailing-lists.ent +++ b/it_IT.ISO8859-15/share/sgml/mailing-lists.ent @@ -1,206 +1,221 @@ freebsd-advocacy@FreeBSD.org"> freebsd-afs@FreeBSD.org"> freebsd-aic7xxx@FreeBSD.org"> freebsd-alpha@FreeBSD.org"> freebsd-announce@FreeBSD.org"> freebsd-arch@FreeBSD.org"> freebsd-arm@FreeBSD.org"> freebsd-atm@FreeBSD.org"> freebsd-audit@FreeBSD.org"> freebsd-binup@FreeBSD.org"> freebsd-bugbusters@FreeBSD.org"> freebsd-bugs@FreeBSD.org"> freebsd-chat@FreeBSD.org"> freebsd-cluster@FreeBSD.org"> cvs-committers@FreeBSD.org"> freebsd-config@FreeBSD.org"> freebsd-core@FreeBSD.org"> freebsd-current@FreeBSD.org"> cvs-all@FreeBSD.org"> freebsd-database@FreeBSD.org"> freebsd-developers@FreeBSD.org"> freebsd-doc@FreeBSD.org"> +doc-committers@FreeBSD.org"> + freebsd-emulation@FreeBSD.org"> freebsd-firewire@FreeBSD.org"> -freebsd-fs@FreeBSD.org"> freebsd-gnome@FreeBSD.org"> freebsd-hackers@FreeBSD.org"> freebsd-hardware@FreeBSD.org"> freebsd-hubs@FreeBSD.org"> freebsd-i18n@FreeBSD.org"> freebsd-ia64@FreeBSD.org"> freebsd-install@FreeBSD.org"> freebsd-ipfw@FreeBSD.org"> freebsd-isdn@FreeBSD.org"> freebsd-isp@FreeBSD.org"> freebsd-java@FreeBSD.org"> freebsd-jobs@FreeBSD.org"> freebsd-lfs@FreeBSD.org"> -freebsd-libh@FreeBSD.org"> +freebsd-mips@FreeBSD.org"> + freebsd-mobile@FreeBSD.org"> freebsd-mozilla@FreeBSD.org"> freebsd-multimedia@FreeBSD.org"> freebsd-net@FreeBSD.org"> freebsd-newbies@FreeBSD.org"> new-bus-arch@bostonradio.org"> freebsd-platforms@FreeBSD.org"> freebsd-policy@FreeBSD.org"> freebsd-ports@FreeBSD.org"> +freebsd-ports-bugs@FreeBSD.org"> + +ports-committers@FreeBSD.org"> + freebsd-ppc@FreeBSD.org"> freebsd-qa@FreeBSD.org"> freebsd-questions@FreeBSD.org"> freebsd-realtime@FreeBSD.org"> freebsd-scsi@FreeBSD.org"> freebsd-security@FreeBSD.org"> freebsd-security-notifications@FreeBSD.org"> freebsd-small@FreeBSD.org"> freebsd-smp@FreeBSD.org"> freebsd-sparc@FreeBSD.org"> +src-committers@FreeBSD.org"> + freebsd-stable@FreeBSD.org"> freebsd-standards@FreeBSD.org"> freebsd-test@FreeBSD.org"> freebsd-tokenring@FreeBSD.org"> freebsd-user-groups@FreeBSD.org"> freebsd-vendors@FreeBSD.org"> freebsd-www@FreeBSD.org"> majordomo@FreeBSD.org"> diff --git a/it_IT.ISO8859-15/share/sgml/translators.ent b/it_IT.ISO8859-15/share/sgml/translators.ent index 42c754ec40..4008e2e423 100644 --- a/it_IT.ISO8859-15/share/sgml/translators.ent +++ b/it_IT.ISO8859-15/share/sgml/translators.ent @@ -1,33 +1,33 @@ sysadmin@alexdupre.com"> andrea_bsd@virgilio.it"> carla@cct.it"> sepry@tin.it"> daniele@cct.it"> daniele@keybit.net"> ale@unixmania.net"> eugenio@openbeer.it"> ferruccio.vitale@tin.it"> gabrielef@zeropiu.it"> gmarco@scotty.masternet.it"> inzet@gufi.org"> +kaosweb@yahoo.it"> lapo@lapo.it"> luca@xunil.it"> -marco.t@remotelab.org"> +m.trentini@remotelab.org"> matteo.niccoli@softecspa.it"> stucchi@willystudios.com"> nivit@libero.it"> rodario@libero.it"> rudy@tzone.it"> bartequi@neomedia.it"> sriva@gufi.org"> surrender_it@yahoo.it"> -thedoc@m4d.sm"> vdaelli@hotmail.com">