docs-common/common legalnotice-content-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13256/docs-common/common
Added Files:
legalnotice-content-it.xml
Log Message:
--- NEW FILE legalnotice-content-it.xml ---
<para>
Sono garatiti i permessi di copiare, distribuire, e/o modificare questo documento sotto
i termini della GNU Free Documentation License, Versione 1.2 o qualsiasi successiva
versione pubblicata dalla Free Software Foundation; con nessuna Invariant
Sections, nessuna Front-Cover Texts, e nessuna Back-Cover Texts. Una copia della
licenza �� disponibile su <ulink
url="http://www.gnu.org/licenses/fdl.html">http://www.gnu.org/licenses/fdl.html</ulink>.
</para>
<para>
Questo documento pu�� essere copiato e distribuito in qualsiasi media, sia
commerciale che non commerciale, premettendo che la GNU Free Documentation
License (FDL), le note sul copyright, e le note di licenza che dicono che la GNU
FDL che si applicano al documento sono riprodotte in tutte le copie, e che tu non
abbia aggiunto nessun altra condizione di sorta a quelle della GNU FDL.
</para>
<para>
Garrett LeSage hanno creato le grafiche di ammonizione (note, tip, important,
caution, e warning).
Tommy Reynolds <email>Tommy.Reynolds(a)MegaCoder.com</email> ha creato la grafica di callout.
Tutte queste possono essere liberamente distribuite con la documentazione
prodotta per il &PROJECT;.
</para>
<para>
&BOOKID;
</para>
<para>
&RH; ed il logo &RH; "Shadow Man" sono marchi registrati di
&FORMAL-RHI; negli Stati United ed in altri paesi.
</para>
<!-- Changing to match RHEL usage, changes are drawn directly from existing -->
<!-- lawyer-approved changes within the RHEL legalnotice:
<para>
&RH;, &RH; Network, the &RH; "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux
Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts,
Rawhide and all &RH;-based trademarks and logos are trademarks or registered
trademarks of &FORMAL-RHI; in the United States and other countries.
</para>
<para>
Linux is a registered trademark of Linus Torvalds.
</para>
<para>
Motif and UNIX are registered trademarks of The Open Group.
</para>
<para>
Intel and Pentium are registered trademarks of Intel Corporation. Itanium
and Celeron are trademarks of Intel Corporation.
</para>
<para>
AMD, AMD Athlon, AMD Duron, and AMD K6 are trademarks of Advanced Micro
Devices, Inc.
</para>
<para>
Windows is a registered trademark of Microsoft Corporation.
</para>
<para>
SSH and Secure Shell are trademarks of SSH Communications Security, Inc.
</para>
<para>
FireWire is a trademark of Apple Computer Corporation.
</para>
-->
<para>
Tutti gli altri marchi e copyrights a cui si fa riferimento sono propriet�� dei
rispettivi proprietari.
</para>
18 years, 5 months
docs-common/common legacynotice-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13233/docs-common/common
Added Files:
legacynotice-it.xml
Log Message:
--- NEW FILE legacynotice-it.xml ---
<note>
<title>DOCUMENTO LEGACY</title>
<para>
Questo documento �� relativo a una versione di &FC; che non �� pi��
supportata dal &FP;. Cambiamenti nelle ultime versioni di &FC; possono aver reso questo
documento inaccurato. Sei pregato di controllare il sito web di &FDP; su
&FDPDOCS-URL; per la versione attuale prima di continuare a leggere questo
documento.
</para>
<para>
Questa versione del documento non sar�� cambiato o emendato, eccetto
per la correzione di errori che possono indurre in perdita di dati o a debolezze nel sistema
di sicurezza. Se credi di aver trovato un errore, sei pregato di
riferirlo mediante &BZ; sul bug &BUG-NUM;.
</para>
</note>
18 years, 5 months
docs-common/common fedora-entities-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13211/docs-common/common
Added Files:
fedora-entities-it.xml
Log Message:
***** Error reading new file: [Errno 2] No such file or directory: 'fedora-entities-it.xml'
18 years, 5 months
docs-common/common draftnotice-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13189/docs-common/common
Added Files:
draftnotice-it.xml
Log Message:
--- NEW FILE draftnotice-it.xml ---
<note>
<title>DRAFT</title>
<para>
Questa �� una versione draft del documento. E' soggetta a cambiamento in qualsiasi momento
e potrebbe non esserne ancora stata provata l'accuratezza tecnica. Se trovi qualsiasi
errore, sei pregato di comunicarli via Bugzilla sul bug &BUG-NUM;.
</para>
</note>
18 years, 5 months
docs-common/common deprecatednotice-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13167/docs-common/common
Added Files:
deprecatednotice-it.xml
Log Message:
--- NEW FILE deprecatednotice-it.xml ---
<note>
<title>DOCUMENTO DEPRECATO</title>
<para>
Questo documento non �� pi�� supportato dal &FDP;. Uno o pi�� delle
seguenti situazioni pu�� essere accaduta:
</para>
<itemizedlist>
<listitem>
<para>
Cambiamenti in Fedora possono aver reso questo documento inaccurate.
</para>
</listitem>
<listitem>
<para>
E' disponibile un documento molto pi�� rilevante.
</para>
</listitem>
<listitem>
<para>
Questo documento potrebbe essere stato incluso in un documento differente.
</para>
</listitem>
</itemizedlist>
<para>
Fa riferimento alla storia delle revisioni per maggiori informazioni.
</para>
</note>
18 years, 5 months
docs-common/common cvs-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13140/docs-common/common
Added Files:
cvs-it.xml
Log Message:
--- NEW FILE cvs-it.xml ---
<!-- $Id: -->
<!--
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY BOILERPLATE "This header makes editing XML easier" >
<!ENTITY FC "Fedora Core" >
<!ENTITY RH "Red Hat" >
]>
-->
<chapter id="ch-cvs">
<title>CVS</title>
<para>
Il Concurrent Versions System (<application>CVS</application>)
fornisce un framework dove molteplici utenti possono editare gli stessi files.
Come puoi immaginare, se un gruppo di utenti edita i files in una singola
directory, il chaos regner��. Usando <application>CVS</application>,
comunque, un gruppo di persone pu�� lavorare con sicurezza sullo stesso gruppo di files.
<application>CVS</application> mantiene la copia master dei files,
e registra chi ha cambiato cosa e quando in un depositorio centrale. Se
insorgssero dei conflitti, <application>CVS</application> te lo far�� sapere.
<application>CVS</application> �� spesso usato affinch�� i programmatori possano
condividere codice, ma funziona bene anche per la documentazione.
</para>
<indexterm>
<primary>cvs</primary>
</indexterm>
<section id="sn-cvs-overview">
<title>Come funziona CVS</title>
<indexterm>
<primary>cvs</primary>
<secondary>come funziona</secondary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary>descrizione</secondary>
</indexterm>
<para>
In molti casi, ogni gruppo di files che costituisce un pacchetto o un progetto
�� immagazzinato come un <firstterm>module</firstterm> sul CVS server.
</para>
<para>
Quando lavori con i files dal <application>CVS</application>, dovrai eseguire il
<firstterm>checkout</firstterm> di una copia del modulo sul
file system locale. Dopo aver modificato uno o pi�� files, dovrai inviarli con un
<firstterm>commit</firstterm> al repositorio centrale
<application>CVS</application> server.
</para>
<para>
Con <application>CVS</application> puoi editare un file senza
prima ottenere il permesso o il locking del file. La parte
<wordasword>concurrent</wordasword> del nome
<application>CVS</application> viene dalla sua capacit�� di
permettere diverse differenti persone di editare differenti parti dello stesso
file. Siccome nessuno dei cambiamenti si sovrappone,
<application>CVS</application> pu�� registrare correttamente i loro cambiamenti.
In caso di cambiamenti duplicati, questi sono marcati chiaramente nei files
e gli autori devono risolvere il problema da soli.
</para>
<para>
Quando commetti i cambiamenti, solo i cambiamenti ai files che il server sa
sono commessi. In altre parole, se crei un file nel checkout locale
di un modulo, il nuovo file non �� automaticamente
inviato al server. Devi prima <firstterm>add</firstterm> il
file al repositorio quindi eseguire il commit. Se rimuovi un file
dal tuo checkout locale di un modulo, dovrai specificare che vuoi
rimuoverlo dal repositorio sul CVS server e quindi
eseguire il commit della rimozione del file.
</para>
<para>
I comandi specifici per eseguire queste operazioni sono discussi in
<xref linkend="sn-cvs-cvscommands"></xref>.
</para>
<para>
Se qualcuno ha modificato il file nel tempo fra intercorso fra l'ultima volta
che l'hai catturato dal CVS e quando hai provato ad eseguire il commit di un cambiamento,
<application>CVS</application> prover�� ad incollare i cambiamenti alla
copia master sul <application>CVS</application> server. Se
il contenuto che hai cambiato �� in una locazione differente nel file
rispetto la contenuto cambiato da qualcun'altro, l'azione del commit
andr�� avanti senza alcun <firstterm>conflitto</firstterm>.
Se qualcuno modifica lo stesso contenuto che hai gi�� cambiato tu
e provi a fare un commit, vedrai un messaggio che �� avvenuto
il conflitto su un file. Cos��, dovrai fare l'
<firstterm>update</firstterm> dei tuoi files di frequente. E' una buona pratica
aggiornarli prima di iniziare a modificarli.
Fa riferimento a <xref linkend="sn-cvs-cvscommands-conflicts"></xref> per
le istruzioni su come risolvere i conflitti.
</para>
</section>
<section id="sn-cvs-preparation">
<title>Preparazione all'uso di CVS</title>
<indexterm>
<primary>cvs</primary>
<secondary>preparazione all'uso</secondary>
</indexterm>
<para>
Prima di usare <application>CVS</application>, hai bisogno di stabilire
un account con il <application>CVS</application> server. Dopo
aver ottenuto un account, non dovrai pi�� fare nuovamente queste
cose.
</para>
<section id="sn-cvs-rpm-check">
<title>E' CVS installato sul tuo sitema</title>
<indexterm>
<primary>cvs</primary>
<secondary>installazione RPM</secondary>
</indexterm>
<para>
Devi aver installato il pacchetto <application>CVS</application>
<abbrev>RPM</abbrev>. Verifica la sua presenza
digitando il comando:
</para>
<screen><prompt>$ </prompt><command>rpm -q cvs</command></screen>
<para>
e vedi un output simile a
<computeroutput>cvs-1.11.19-1</computeroutput>, allora il pacchetto
�� installato. Un messaggio simile a <computeroutput>package cvs
is not installed</computeroutput> vuol dire che devi instllare il
pacchetto <application>cvs</application> prima di continuare. Se
non sai come fare, consulta il tuo amministratore di sistema
che potr�� intallarlo per te.
</para>
</section>
<section id="sn-cvs-generate-keys">
<title>Generazione dell chiavi SSH</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>chiavi di autorizzazione</secondary>
</indexterm>
<para>
Il <application>CVS</application> server usa chiavi
<application>SSH</application> Protocol 2 per autenticare
gli utenti. Cos��, devi generare un paio di chiavi prima di richiedere
un account <application>CVS</application>. Se hai gi��
una chiave <application>SSH</application> <abbrev>DSA</abbrev>,
puoi saltare questo passaggio.
</para>
<tip>
<title>Tip</title>
<para>
Hai gi�� una chiave <abbrev>DSA</abbrev> se hai il
file <filename>~/.ssh/id_dsa.pub</filename> sul sistema.
</para>
<para>
Se la tua chiave <abbrev>DSA</abbrev> esistente non richiede una
<wordasword>passphrase</wordasword>, sei fortemente incoraggiato a
generrne una che richieda una passphrase.
</para>
</tip>
<para>
Usa i seguenti passi per generare una chiave <abbrev>DSA</abbrev>
usata da <application>SSH</application> Protocol 2. E'
necessaria per un account <application>CVS</application> su
<computeroutput>cvs.fedora.redhat.com</computeroutput>.
</para>
<orderedlist>
<indexterm>
<primary>OpenSSH</primary>
<secondary><command>ssh-keygen</command>
</secondary>
</indexterm>
<indexterm>
<primary><command>ssh-keygen</command>
</primary>
</indexterm>
<listitem>
<para>
Per generare una chiave
<acronym>DSA</acronym>
per funzionare con il protocollo versione 2.0, allo shell prompt,
digita il comando:
</para>
<screen><prompt>$ </prompt><command>ssh-keygen -t dsa</command></screen>
<para>
Accetta la posizione predefinita per la locazione del file
<filename>~/.ssh/id_dsa</filename>. Sei fortemente incoraggiato all'urgenza
di definire ed usare una <firstterm>passphrase</firstterm> per
aumentare la sicurezza della tua chiave. Immetti una passphrase
differente dalla password del tuo password e confermala
reinserendola nuovamente.
</para>
</listitem>
<listitem>
<para>
Copia la nuova chiave nel file corretto digitando i
seguenti comandi allo shell prompt.
</para>
<screen><prompt>$ </prompt><command>cat ~/.ssh/id_dsa.pub>>~/.ssh/authorized_keys</command></screen>
<note>
<para>
Controlla con attenzione questo comando prima di premere il tasto
<guibutton>ENTER</guibutton>.
Se <filename>~/.ssh/authorized_keys</filename>
esiste gi��, i contenuti di
<filename>~/.ssh/id_dsa.pub</filename> verranno appesi alla
fine del file <filename>~/.ssh/authorized_keys</filename>.
</para>
</note>
</listitem>
<listitem>
<para>
Cambia i permessi della tua directory <filename>~/.ssh</filename>
e delle tue chiavi con i comandi:
</para>
<screen><prompt>$ </prompt><command>chmod 755 ~/.ssh</command>
<prompt>$ </prompt><command>chmod 644 ~/.ssh/authorized_keys</command></screen>
</listitem>
</orderedlist>
<tip>
<title>Tip</title>
<para>
Puoi far si che il sistema ricordi la passphrase cos�� da
non doverla digitare ogni volta che accedi al
<application>CVS</application> server. Fa riferimento alla
documentazione del programma <application>ssh-add</application>.
</para>
</tip>
</section>
</section>
<section id="sn-cvs-config">
<title>Configurazione per l'accesso CVS</title>
<indexterm>
<primary>cvs</primary>
<secondary>configurazione per l'accesso</secondary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary>CVSROOT</secondary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary>CVS_RSH</secondary>
</indexterm>
<indexterm>
<primary>CVSROOT</primary>
</indexterm>
<indexterm>
<primary>CVS_RSH</primary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary><filename>.cvsrc</filename>
</secondary>
</indexterm>
<indexterm>
<primary><filename>.cvsrc</filename>
</primary>
</indexterm>
<section id="sn-cvs-config-cvsrc">
<title>Evitare digitazioni ripetitive</title>
<indexterm>
<primary>cvs</primary>
<secondary>evitare digitazioni ripetitive</secondary>
</indexterm>
<para>
Molti comandi <application>CVS</application> hanno bisogno di
certe opzioni per operare in modo consistente. Invece di
digitarle ogni volta che il comando �� usato, puoi salvare gli
switches in un file che <application>CVS</application> legger��
prima di eseguire la linea di comando.
</para>
<para>
Crea un file chiamato <filename>~/.cvsrc</filename> nella tua home
directory. Dovr�� contenere i seguenti comandi, uno per
riga:
<screen><computeroutput>cvs -z3
diff -uNp
rdiff -uNp
update -dP</computeroutput></screen>
</para>
</section>
<section id="sn-cvs-config-anon">
<title>Configurare un accesso CVS Read-Only</title>
<indexterm>
<primary>cvs</primary>
<secondary>configurare un accesso Read-Only</secondary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary>accesso anonimo</secondary>
</indexterm>
<para>
If your goal is to download the various &FC; documents and to
render them on your system, you only need read-only access to
the <application>CVS</application> repository. Follow the
instructions in this section and then skip directly to
<xref linkend="sn-cvs-cvscommands-co"/>.
</para>
<para>
Change directories to where you want your files from
<application>CVS</application> to be located, and execute the
following commands:
</para>
<screen><prompt>$ </prompt><command>export CVSROOT=:pserver:cvs.fedora.redhat.com:/cvs/docs</command>
<prompt>$ </prompt><command>cvs login</command>
<prompt>$ </prompt><command>cvs checkout docs-common</command> <replaceable>module-name</replaceable>
<prompt>$ </prompt><command>cvs checkout</command> <replaceable>module-name</replaceable>
<prompt>$ </prompt><command>cd</command> <replaceable>module-name</replaceable></screen>
<para>
Once you have checked the module out, it doesn't matter what
your
<envar>CVSROOT</envar>
is set to because it is stored in the file
<filename>CVS/Root</filename> for each directory in your local
repository. As long as your current working directory has a
<filename>CVS/</filename> directory, the
<application>CVS</application> program will automatically locate
the &FC; repository.
</para>
</section>
<section id="sn-cvs-config-author">
<title>Configuring Read/Write CVS Access</title>
<indexterm>
<primary>cvs</primary>
<secondary>configuring read/write access</secondary>
</indexterm>
<indexterm>
<primary>cvs</primary>
<secondary>configuring access for authors</secondary>
</indexterm>
<para>
To author a new document or to change an existing one, you must
obtain full read/write access to the &FC; Docs
<application>CVS</application> repository. For the full details
on this process, refer to the
<ulink url="http://fedoraproject.org/wiki/DocsProject/NewWriters"><filename>http://fedoraproject.org/wiki/DocsProject/NewWriters</filename>
</ulink> web site. Below is a summary:
</para>
<itemizedlist>
<listitem>
<para>
Subscribe to the
<ulink url="https://listman.redhat.com/mailman/listinfo/fedora-docs-list"><filename>fedora-docs-list</filename>
</ulink>, which is the main forum for the project.
</para>
</listitem>
<listitem>
<para>
Generate a GNU Privacy Guard (<abbrev>GPG</abbrev>) key to
identify yourself to the project.
</para>
</listitem>
<listitem>
<para>
Register for a
<ulink url="http://bugzilla.redhat.com/"><filename>Bugzilla</filename>
</ulink> account, if you do not have one already.
<filename>Bugzilla</filename> is how we keep track of bugs,
changes and projects.
</para>
</listitem>
<listitem>
<para>
Post a
<ulink url="http://fedoraproject.org/wiki/DocsProject_2fSelfIntroduction">self
introduction</ulink> to the list.
</para>
</listitem>
</itemizedlist>
<para>
After your
<ulink url="http://fedoraproject.org/wiki/DocsProject_2fSelfIntroduction">self
introduction</ulink> has been approved your
<application>CVS</application> access will be granted.
</para>
<para>
Every author, and that includes you once your self introduction
has been received, has a unique
<envar>$CVSROOT</envar>
to access the <application>CVS</application> repository:
</para>
<screen><prompt>$ </prompt><command>export CVSROOT=:ext:</command><replaceable>yourname</replaceable><command>@cvs.fedora.redhat.com:/cvs/docs</command>
<prompt>$ </prompt><command>export CVS_RSH=/usr/bin/ssh</command></screen>
<para>
With the
<envar>$CVSROOT</envar>
and
<envar>$CVS_RSH</envar>
environment variables in place, you can access the repository:
</para>
<screen><prompt>$ </prompt><command>cvs co -c</command></screen>
<para>
You will be asked for the passphrase for your
<application>SSH</application> key. Press
<guibutton>ENTER</guibutton>
and you should receive a list of modules already in the
repository.
</para>
</section>
</section>
<section id="sn-cvs-cvscommands">
<title>Basic CVS Commands</title>
<indexterm>
<primary>cvs</primary>
<secondary>commands</secondary>
</indexterm>
<para>
After configuring your system to work with CVS, checkout the
modules you will be working on.
</para>
<tip>
<title>Tip</title>
<para>
To see if you need a correctly-set
<envar>$CVSROOT</envar>
variable, or the <option>-m </option>
<replaceable>repository</replaceable> command line switch, see
if you have a <filename>CVS/</filename> subdirectory in your
working directory.
</para>
<para>
If you have a <filename>CVS/</filename> directory,
<application>CVS</application> ignores any
<envar>$CVSROOT</envar>
or <option>-m</option> command line switch.
</para>
</tip>
<section id="sn-cvs-cvscommands-co">
<title>Checking Out Modules</title>
<indexterm>
<primary>cvs</primary>
<secondary>checking out modules</secondary>
</indexterm>
<para>
You only need to checkout a module once. After a local copy of
the module is on your system, it is on your system.
</para>
<para>
To checkout a module, use the following command:
</para>
<screen><prompt>$ </prompt><command>cvs co</command> <replaceable><module-name></replaceable></screen>
<para>
For example, to checkout the
<computeroutput>example-tutorial</computeroutput> module, change
to your work directory, and execute the following command:
</para>
<screen><prompt>$ </prompt><command>cvs co example-tutorial</command></screen>
<para>
A directory called <filename>example-tutorial/</filename> is
created in the current directory.
</para>
<para>
If a branch name is not specified when checking out a module, it
is referred to as the <firstterm>HEAD</firstterm> of the
<application>CVS</application> module.
</para>
<section id="sn-cvs-cvscommands-co-branch">
<title>Checking Out Branches of Modules</title>
<indexterm>
<primary>cvs</primary>
<secondary>check out modules</secondary>
<tertiary>checking out branches</tertiary>
</indexterm>
<para>
Think of a <application>CVS</application> branch as a version
of the files for a particular version of a manual or package.
</para>
<para>
To checkout a branch of a module, use the following command:
</para>
<screen><prompt>$ </prompt><command>cvs co</command> <option>-d</option> <replaceable><directory></replaceable> <option>-r</option> <replaceable><branchname></replaceable> <replaceable><module-name></replaceable></screen>
<para>
A directory named <replaceable><directory></replaceable>
is created, and the files for the
<replaceable><branchname></replaceable> branch of the
<replaceable><module-name></replaceable> module are
copied in the directory.
</para>
<para>
For example, to checkout a branch named BRANCH-VERSION-1.2
from the <computeroutput>mymodule</computeroutput> module, use
the command:
</para>
<screen><prompt>$ </prompt><command>cvs co -d mymodule-1.2 -r BRANCH-VERSION-1.2 mymodule</command></screen>
<para>
The BRANCH-VERSION-1.2 branch of the module is checked out in
the <filename>mymodule-1.2</filename> directory on your
system.
</para>
<para>
To determine which branches and tags exist for a file, use the
command:
</para>
<screen><prompt>$ </prompt><command>cvs status</command> <option>-v</option> <replaceable><filename></replaceable></screen>
<para>
For example, the status of the file
<filename>foo.sgml</filename> is as follows:
</para>
<screen>
<computeroutput>
===================================================================
File: foo.sgml Status: Up-to-date
Working revision: 1.47
Repository revision: 1.47 /cvs/docs/custom-guide/rhl-cg-en.sgml,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
BRANCH-VERSION-1.2 (branch: 1.25.2)
</computeroutput>
</screen>
<para>
Only tags marked as branches in the second column under the
<computeroutput>Existing Tags</computeroutput> section can be
checked out as a branch.
</para>
</section>
</section>
<section id="sn-cvs-cvscommands-up">
<title>Updating Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>updating files</secondary>
</indexterm>
<para>
To retrieve the latest versions of the files in a module, change
to the directory that contains the files for the module and
execute the command:
</para>
<screen><command>cvs update</command></screen>
<para>
The latest versions of all the files in the module are
downloaded into your local copy. If you notice a file conflict,
refer to <xref linkend="sn-cvs-cvscommands-conflicts"></xref>.
</para>
</section>
<section id="sn-cvs-cvscommands-commit">
<title>Committing Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>committing files</secondary>
</indexterm>
<para>
After modifying files in your local version of a module, commit
them to save the changes on the <application>CVS</application>
server:
</para>
<screen><prompt>$ </prompt><command>cvs commit</command> <option>-m</option> "<replaceable>some log message</replaceable>" <replaceable>filename</replaceable></screen>
<note>
<para>
If you would prefer to write your log message with your
favorite text editor, as defined by the $VISUAL or the $EDITOR
environment variable, just omit the <userinput>-m "some
log message"</userinput>. The buffer will already contain
comments describing the change; you do not need to delete them
as you enter your own text.
</para>
</note>
<para>
The log message should be as descriptive as possible so that you
and anyone else working on the module understands what changed.
Using a log message such as <userinput>updated some
files</userinput> does not accurately describe what has changed
and will not help you in the future. If you are correcting a
bug, use the <application>Bugzilla</application> reference.
</para>
<para>
The <replaceable><filename></replaceable> can be one
filename, a series of filenames separated by spaces, or a group
of filenames specified using wildcards such as
<filename>*.png</filename> or <filename>foo-*.sgml</filename>.
</para>
<para>
If no filename or group of filenames is specified in the
<command>commit</command> command, all outstanding changes of
any kind are committed to the server. The command is recursive
and will include changes in any subdirectories of the module.
Use caution when issuing the <command>commit</command> command
without any filenames because you might not remember exactly
what files changed.
</para>
<para>
If you notice a file conflict, refer to
<xref linkend="sn-cvs-cvscommands-conflicts"></xref>.
</para>
</section>
<section id="sn-cvs-cvscommands-add">
<title>Adding Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>adding files</secondary>
</indexterm>
<para>
To add a file to a module, create the file in your local copy
then execute the following command:
</para>
<screen><prompt>$ </prompt><command>cvs add</command> <replaceable>file-to-add</replaceable></screen>
<para>
After adding the file, you must <command>commit</command> the
<command>add</command> to copy it to the server:
</para>
<screen><prompt>$ </prompt><command>cvs commit</command> <option>-m</option> "<replaceable>some log message</replaceable>" <replaceable>file-to-add</replaceable></screen>
</section>
<section id="sn-cvs-cvscommands-admin">
<title>Managing Binary Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>binary files</secondary>
</indexterm>
<para>
The most commonly-archived files are simple text files but
sometimes binary files are also archived. The
<application>cvs</application> program recognizes most common
filename extentions such as <filename>.png</filename> or
<filename>.jpg</filename>, so <application>cvs</application>
usually "does the right thing".
</para>
<para>
When a copy of a file is checked out of the repository,
<application>cvs</application> scans it for special keywords,
such as "<computeroutput>$id:$</computeroutput>" and
replaces the string with a generated value, such as the file
version number.
</para>
<para>
This keyword substitution usually corrupts binary files, so it
must be turned off if <application>cvs</application> does not
recognize your file as binary. To mark your file as being
binary, and thus needing the keyword expansion turned off, use
the command:
</para>
<screen width="60"><prompt>$ </prompt><command>cvs</command> <option>admin</option> <option>-kk</option> <replaceable>filename</replaceable></screen>
<para>
Note that the file must already be checked in to the
<abbrev>CVS</abbrev> repository before the
<option>admin</option> command can be used. This is OK, since
the keyword expansion is done as the file is checked out and
copied to the local directory, not when the file is committed to
the repository.
</para>
<tip>
<title>Recovering a binary file</title>
<para>
If you check a binary file into the repository and then find
it corrupted when it is checked out, do not panic. Simply use
the <option>admin</option> command as described above, delete
your local file copy, and check it out again.
</para>
</tip>
</section>
<section id="sn-cvs-cvscommands-rm">
<title>Removing Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>removing files</secondary>
</indexterm>
<para>
If a file is no longer needed in the module, use the
<command>remove</command> command to remove it from your local
copy and then <command>commit</command> the removal to the
server. Even though the file is removed from current version of
the module, an archived copy is still kept on the server and can
be retrieved at any time with the <command>add</command>
command.
</para>
<screen><prompt>$ </prompt><command>cvs rm -f</command> <replaceable>file-to-remove</replaceable></screen>
<para>
After removing the file, you must <command>commit</command> the
removal:
</para>
<screen><prompt>$ </prompt><command>cvs commit</command> <option>-m</option>"<replaceable>some log message</replaceable>" <replaceable>file-to-remove</replaceable></screen>
<para>
You can not use wildcards in the <command>commit</command>
command to identify removed files. They must be specified with a
exact filename.
</para>
<para>
If you need to rename a file, it is best to rename the file on
the <application>CVS</application> server so that the history of
the file is preserved. If you need to rename a file, send an
email to
<ulink url="mailto:cvsdocs-administrator@fedora.redhat.com"><filename>cvsdocs-administrator(a)fedora.redhat.com</filename>
</ulink> asking to have the file renamed.
</para>
</section>
<section id="sn-cvs-cvscommands-status">
<title>Status of Files</title>
<indexterm>
<primary>cvs</primary>
<secondary>status of files</secondary>
</indexterm>
<para>
Sometimes it is necessary to view the
<firstterm>status</firstterm> of a file in a
<application>CVS</application> module. To view the status of a
file, use the command:
</para>
<screen><prompt>$ </prompt><command>cvs status</command> <replaceable>filename</replaceable></screen>
<para>
The status report of a repository file is as follows:
</para>
<variablelist>
<varlistentry>
<term><computeroutput>Up-to-date</computeroutput></term>
<listitem>
<para>
Your revision of the file is identical to the latest
revision on the <application>CVS</application> server.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Locally Modified</computeroutput></term>
<listitem>
<para>
You have updated to the latest revision from the server,
but then you modified the file on your system.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Locally Added</computeroutput></term>
<listitem>
<para>
You added the file with the <command>cvs add</command>
command but have not yet committed the addition of the
file.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Locally Removed</computeroutput></term>
<listitem>
<para>
You removed the file with the <command>cvs
remove</command> command but have not yet committed the
removal.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Needs Checkout</computeroutput></term>
<listitem>
<para>
A newer version of the file is on the server and needs to
be retrieved. Even though the status includes the word
checkout, it really means that you need to update your
files with the <command>cvs update</command> command.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Needs Patch</computeroutput></term>
<listitem>
<para>
The revision in your local checkout needs a patch to be
the latest revision from the server. Issue the
<command>cvs update</command> command to resolve.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Needs Merge</computeroutput></term>
<listitem>
<para>
A newer revision exists on the server and your local
version contains modification not yet committed. This
status usually occurs if you don't have the latest
revision of the file and edit it anyway.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>File had conflicts on merge</computeroutput></term>
<listitem>
<para>
Similar to <computeroutput>Needs Merge</computeroutput>,
except when you tried to issue the <command>cvs
update</command> command, the differences could not be
resolved automatically. Refer to
<xref linkend="sn-cvs-cvscommands-conflicts"></xref> for
more information on resolving conflicts.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>Unknown</computeroutput></term>
<listitem>
<para>
The <application>CVS</application> server does not know
anything about this file. It has neither been added nor
removed locally and has never been committed to the
server. This status usually occurs for files you should
not commit to <application>CVS</application> such as
<filename>generated-index.sgml</filename> or for files
that you want to add to the repository but have not yet
issued the <command>cvs add</command> command.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="sn-cvs-cvscommands-conflicts">
<title>Resolving Conflicts</title>
<indexterm>
<primary>cvs</primary>
<secondary>resolving conflicts</secondary>
</indexterm>
<para>
If you modify a file and the same region is modified by someone
else and committed first, you will probably see a message
similar to the following when committing the file or updating
your local copy of the module:
</para>
<screen>
<computeroutput>
RCS file: /cvs/docs/module-name/filename.sgml,v
retrieving revision 1.12
retrieving revision 1.13
Merging differences between 1.12 and 1.13 into filename.sgml
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in filename.sgml
C filename.sgml
</computeroutput>
</screen>
<para>
To resolve the conflict, open the file, search for
<computeroutput><<<<<<<</computeroutput>
and determine which version of the content is correct. For
example:
</para>
<screen>
<computeroutput>
<para>
Some sentence.
<<<<<<< filename.sgml
A sentence that was changed in the working copy.
=======
A same sentence that was changed differently and committed.
>>>>>>> 1.13
</para>
</computeroutput>
</screen>
<para>
The content between the
<computeroutput><<<<<<<</computeroutput>,
and the <computeroutput>=======</computeroutput> is the content
from your working copy. The content between the
<computeroutput>=======</computeroutput> and the
<computeroutput>>>>>>>></computeroutput> is
the content from the server.
</para>
<para>
Resolve the conflict by editing your copy, and commit the file.
</para>
</section>
<section id="sn-cvs-cvscommands-summary">
<title>Summary</title>
<indexterm>
<primary>cvs</primary>
<secondary>commands</secondary>
<tertiary>summary of</tertiary>
</indexterm>
<para>
All commands assume you are in the proper directory for the
<application>CVS</application> module.
</para>
<table frame="all" id="tb-cvs-basic-commands">
<title>Basic CVS Commands</title>
<tgroup cols="2">
<colspec colnum="1" colname="shortcut" colwidth="30"/>
<colspec colnum="2" colname="description" colwidth="60"/>
<thead>
<row>
<entry>Command</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><command>cvs checkout
<replaceable><module-name></replaceable></command>
or <command>cvs co <replaceable><module-name></replaceable></command>
</entry>
<entry>Creates a directory called
<replaceable><module-name></replaceable> with the contents of the
module in the directory</entry>
</row>
<row>
<entry><command>cvs co -d <replaceable><directory></replaceable> -r <replaceable><branchname></replaceable><replaceable><module-name></replaceable></command>
</entry>
<entry>Creates the <replaceable><directory></replaceable> directory
with the contents of the <replaceable><branchname></replaceable>
branch of the <replaceable><module-name></replaceable> module</entry>
</row>
<row>
<entry><command>cvs update</command> or <command>cvs up</command>
</entry>
<entry>Update your files with the latest files from the CVS server</entry>
</row>
<row>
<entry><command>cvs add <replaceable><filename></replaceable></command>
</entry>
<entry>Add a new file "filename" to the CVS server</entry>
</row>
<row>
<entry><command>cvs commit -m "My message"
<replaceable><filename></replaceable></command>
</entry>
<entry>Update file <replaceable><filename></replaceable> with the
latest copy from your computer</entry>
</row>
<row>
<entry><command>cvs log <replaceable><filename></replaceable></command>
</entry>
<entry>View the commit messages for the file <replaceable><filename></replaceable>
</entry>
</row>
<row>
<entry><command>cvs status <replaceable><filename></replaceable></command>
</entry>
<entry>View status of the file, such as <computeroutput>Locally
Modified</computeroutput>
</entry>
</row>
<row>
<entry><command>cvs status -v <replaceable><filename></replaceable></command>
</entry>
<entry>View existing tags and branches for file</entry>
</row>
<row>
<entry><command>cvs diff <replaceable><filename></replaceable></command>
</entry>
<entry>Show diff of the working copy of the file and the latest
version of the file for the branch</entry>
</row>
<row>
<entry><command>cvs diff -r1.1 -r1.2 <replaceable><filename></replaceable></command>
</entry>
<entry>Show diff of version 1.1 and 1.2 for file</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
For more information, read the CVS manual available on your
system at
<filename>/usr/share/doc/cvs-<replaceable><version-number></replaceable>/cvs.ps</filename>
(the CVS version might vary) and visit the CVS webpage available
at
<ulink url="http://www.cvshome.org/">http://www.cvshome.org/</ulink>.
</para>
<tip>
<title>Tip</title>
<para>
Since <application>CVS</application> is using
<application>ssh</application> to connect to the
<application>CVS</application> server, you will be prompted
your password before performing your
<application>CVS</application> request. If you want to
configure your machine so that you do not have to enter a
password, refer to the
<ulink url="http://redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-openssh..."><citetitle>&RH;
Linux 9 Customization Guide</citetitle> </ulink> for details
about using <command>ssh-agent</command>.
</para>
</tip>
</section>
</section>
</chapter>
18 years, 5 months
docs-common/common bugreporting-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/docs-common/common
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13110/docs-common/common
Added Files:
bugreporting-it.xml
Log Message:
--- NEW FILE bugreporting-it.xml ---
<tip>
<title>Comunicare un errore sul Documento</title>
<para>
Per comunicare un errore o un omissione su questo documento, inviate un rapporto d'errore in &BZ;
su &BZ-URL;. Quando invii il tuo errore, seleziona "&BZ-PROD;" come
<systemitem>Product</systemitem>, e seleziona il titolo di questo documento come
<systemitem>Component</systemitem>. La versione di questo documento ��
&BOOKID;.
</para>
<para>
I manutentori di questo documento riceveranno automaticamente il tuo rapporto d'errore.
A favore dell'intera comunit�� &FED;, grazie per averci aiutato ad
aggiornarci.
</para>
</tip>
18 years, 5 months
install-guide Makefile,1.11,1.12
by fedora-docs-commits@redhat.com
Author: kwade
Update of /cvs/docs/install-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv9706
Modified Files:
Makefile
Log Message:
Hoping I'm using this new Makefile correctly, I get errors during the build but it builds anyway, as is the way of HTML. Please confirm I've done the right thing. One advantage is, now the other languages should become available through Docs Rawhide.
Index: Makefile
===================================================================
RCS file: /cvs/docs/install-guide/Makefile,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Makefile 21 Sep 2005 01:17:52 -0000 1.11
+++ Makefile 19 Nov 2005 18:24:19 -0000 1.12
@@ -1,19 +1,99 @@
###############################################################################
# Makefile for RHLP docs project
# Created by: Tammy Fox <tfox(a)redhat.com>
-# Last edited by: Tammy Fox <tfox(a)redhat.com>
+# Last edited by: Tommy Reynolds <Tommy.Reynolds(a)MegaCoder.com>
# WARNING: need passivetex 1.24 for pdf generation to work
# License: GPL
# Copyright 2003 Tammy Fox, Red Hat, Inc.
+# Copyright 2005 Tommy Reynolds, MegaCoder.com
###############################################################################
+#
+# Document-specific definitions.
+#
+LANGUAGES = en ja_JP zh_CN
+DOCBASE = fedora-install-guide
-LANGUAGES = en
-DOCBASE = fedora-install-guide
-XMLEXTRAFILES-en =
+define XMLEXTRAFILES_template
+XMLEXTRAFILES-$(1)=fedora-install-guide-abouttoinstall-$(1).xml fedora-install-guide-acknowledgements-$(1).xml fedora-install-guide-beginninginstallation-$(1).xml fedora-install-guide-bootloader-$(1).xml fedora-install-guide-diskpartitioning-$(1).xml fedora-install-guide-$(1).xml fedora-install-guide-firewallconfig-$(1).xml fedora-install-guide-firstboot-$(1).xml fedora-install-guide-installingpackages-$(1).xml fedora-install-guide-installtypes-$(1).xml fedora-install-guide-intro-$(1).xml fedora-install-guide-locale-$(1).xml fedora-install-guide-networkconfig-$(1).xml fedora-install-guide-nextsteps-$(1).xml fedora-install-guide-other-instmethods-$(1).xml fedora-install-guide-packageselection-$(1).xml fedora-install-guide-rootpassword-$(1).xml fedora-install-guide-timezone-$(1).xml fedora-install-guide-upgrading-$(1).xml
+endef
+$(foreach LANG,${LANGUAGES},$(eval $(call XMLEXTRAFILES_template,${LANG})))
+
+#
######################################################
include ../docs-common/Makefile.common
######################################################
-$(DOCNAME)/index.html::
- mkdir -p $(DOCNAME)/figs
- cp figs/*.png figs/*.eps $(DOCNAME)/figs
+#
+# If you want to add additional steps to any of the
+# targets defined in "Makefile.common", be sure to use
+# a double-colon in your rule here. For example, to
+# print the message "FINISHED AT LAST" after building
+# the HTML document version, uncomment the following
+# line:
+#${DOCBASE}-en/index.html::
+# echo FINISHED AT LAST
+######################################################
+# Some packaging specific vars
+VERSION=$(shell grep BOOKID $(DOCBASE)-en.xml | sed 's/<!ENTITY BOOKID "[^0-9\.]\+//' | sed 's/ .\+//')
+DATE=${shell grep BOOKID $(DOCBASE)-en.xml | sed 's/.\+(//' | sed 's/).\+//' }
+NOW=$(shell date +"%a %b %e %Y")
+SPECIN=../docs-common/packaging/fedora-doc.spec.in.common
+OMFIN=../docs-common/packaging/fedora-doc.omf.in.common
+DESKTOPIN=../docs-common/packaging/fedora-doc.desktop.in.common
+DOCSPEC=$(PWD)/SPECS/$(DOCBASE).spec
+DOCOMF=$(PWD)/SOURCES/fedora-doc-$(DOCBASE)-C.omf
+DOCDESKTOP=$(PWD)/SOURCES/fedora-doc-$(DOCBASE).desktop
+DOCSRCTAR=$(PWD)/SOURCES/$(DOCBASE)-$(VERSION).src.tar.gz
+TITLE=$(shell ../docs-common/packaging/titlegrab.py $(DOCBASE)-en.xml | sed 's/^ \+//')
+######################################################
+# Some RPM flags...
+######################################################
+RPMFLAGS=--define "docbase $(DOCBASE)" --define "version $(VERSION)" --define "_topdir $(PWD)"
+######################################################
+
+
+clean::
+ rm -rf fedora-doc-$(DOCBASE)*.rpm
+
+
+rpm: clean
+#
+# Make RPM-compliant tarball of source XML and other stuff
+ mkdir $(DOCBASE)-$(VERSION)
+ find . -maxdepth 1 -type f ! \( -name '*~' -o -name 'Makefile*' \) \
+ | cpio -pamdv $(DOCBASE)-$(VERSION)
+ find . -maxdepth 1 -type d ! \( -name '$(DOCBASE)-$(VERSION)' \
+ -o -name 'CVS' -o -name '*~' -o -name '$(DOCBASE)*' \) \
+ | cpio -pamdv $(DOCBASE)-$(VERSION)
+#
+# Make RPM build tree; don't rely on local user's setup
+ mkdir -p {BUILD,RPMS/noarch,SOURCES,SPECS,SRPMS}
+ tar -zcvf $(DOCSRCTAR) $(DOCBASE)-$(VERSION)
+ rm -rf $(DOCBASE)-$(VERSION)/
+#
+# Make rpmlint happy with a changelog entry
+# FIXME: Maybe more magic would make this stickier; pity
+# I'm no magician...
+ sed 's/\(%changelog\)/\1\n* $(NOW) Fedora Docs Project <fedora-docs-list(a)redhat.com> - $(VERSION)-1\n- Update to version $(VERSION)\n/' \
+ $(SPECIN) > $(DOCSPEC)
+#
+# Fill in files
+# FIXME: Needs to be multiplexed for LANGUAGES (see above)
+ cp $(OMFIN) $(DOCOMF)
+ cp $(DESKTOPIN) $(DOCDESKTOP)
+ sed -i 's/@VERSION@/$(VERSION)/g' $(DOCOMF)
+ sed -i 's/@DATE@/$(DATE)/g' $(DOCOMF)
+ sed -i 's/@TITLE@/$(TITLE)/g' $(DOCOMF)
+ sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCOMF)
+ sed -i 's/@VERSION@/$(VERSION)/g' $(DOCDESKTOP)
+ sed -i 's/@DATE@/$(DATE)/g' $(DOCDESKTOP)
+ sed -i 's/@TITLE@/$(TITLE)/g' $(DOCDESKTOP)
+ sed -i 's/@DOCBASE@/$(DOCBASE)/g' $(DOCDESKTOP)
+#
+# Do the build...
+#
+ rpmbuild -bb $(RPMFLAGS) $(DOCSPEC)
+ mv RPMS/noarch/*.rpm .
+ rpmbuild --clean --rmsource $(RPMFLAGS) $(DOCSPEC)
+ rm -rf {BUILD,RPMS,SOURCES,SPECS,SRPMS}
+ rm -rf $(DOCBASE)-$(VERSION)
18 years, 5 months
selinux-faq selinux-faq-it.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/selinux-faq
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv25530/selinux-faq
Added Files:
selinux-faq-it.xml
Log Message:
--- NEW FILE selinux-faq-it.xml ---
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!-- *************** Bring in Fedora entities *************** -->
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../docs-common/common/fedora-entities-en.ent">
%FEDORA-ENTITIES-EN;
<!ENTITY BOOKID "selinux-faq-1.3-8 (2005-01-20-T16:20-0800)"> <!-- version of manual and date -->
<!-- ************** local entities *********** -->
<!ENTITY APACHE "Apache HTTP">
<!ENTITY LOCALVER "3"> <!-- Set value to your choice, when guide version is out -->
<!-- of sync with FC release, use instead of FEDVER or FEDTESTVER -->
<!ENTITY BUG-URL
"https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%...!
;20of%20FAQ%20%28found%20on%0D%0Ahttp%3A%2F%2Ffedora.redhat.com%2Fdocs%2Fselinux-faq-fc3%2Fln-legalnotice.html%29%2C%0D%0Afor%20example%3A%0D%0A%0D%0A%20%20selinux-faq-1.3-8%20%282005-01-20-T16%3A20-0800%29%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A&keywords=&dependson=&blocked=118757%20%20&maketemplate=Remember%20values%20as%20bookmarkable%20template&form_name=enter_bug">
]>
<article id="selinux-faq" lang="it">
<articleinfo>
<title>&FC; &LOCALVER; &SEL; FAQ</title>
<copyright>
<year>2004</year>
<holder>&FORMAL-RHI;</holder>
</copyright>
<authorgroup>
<author>
<surname>Wade</surname>
<firstname>Karsten</firstname>
</author>
<!-- Italian locale by tombo(a)adamantio.net -->
</authorgroup>
&LEGALNOTICE;
</articleinfo>
<section id="s-selinux-faq">
<title>&SEL; Note e FAQ</title>
<para>
Le informazioni in questa FAQ sono pregevoli per coloro che sono nuovi a &SEL;. Il
loro valore �� apprezzabile anche se siete nuovi alle ultime implementazioni di &SEL; in &FC;, poich��
alcuni comportamenti potrebbero essere differenti da come sapete.
</para>
<note>
<title>Questa FAQ �� specifica per &FC; &LOCALVER;</title>
<para>
Se state cercando le FAQ per &FC; 2, fate riferimento a <ulink
url="http://fedora.redhat.com/docs/selinux-faq-fc2/" />.
</para>
</note>
<para>
Per maggiori informazioni su come funziona &SEL;, come usare &SEL; su distribuzioni
Linux generiche e specifiche, e come scrivere policy, queste sono risorse utili:
</para>
<itemizedlist id="external-link-list">
<title>Lista Link Esterni</title>
<listitem>
<para>
NSA &SEL; main website — <ulink
url="http://www.nsa.gov/selinux/" />
</para>
</listitem>
<listitem>
<para>
NSA &SEL; FAQ — <ulink
url="http://www.nsa.gov/selinux/info/faq.cfm" />
</para>
</listitem>
<listitem>
<para>
&SEL; community page — <ulink
url="http://selinux.sourceforge.net" />
</para>
</listitem>
<listitem>
<para>
UnOfficial FAQ — <ulink
url="http://www.crypt.gen.nz/selinux/faq.html" />
</para>
</listitem>
<listitem>
<para>
Writing SE Linux policy HOWTO — <ulink
url="https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=2..."
/>
</para>
</listitem>
<listitem>
<para>
Getting Started with SE Linux HOWTO: the new SE Linux (Debian) —
<ulink
url="https://sourceforge.net/docman/display_doc.php?docid=20372&group_id=2..." />
</para>
</listitem>
<listitem>
<para>
On IRC — irc.freenode.net, #fedora-selinux
</para>
</listitem>
<listitem>
<para>
&FED; mailing list — <ulink
url="mailto:fedora-selinux-list@redhat.com" />;
leggi gli archivi o sottoscriviti su <ulink
url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list" />
</para>
</listitem>
</itemizedlist>
<tip>
<title>Fare cambiamenti/aggiunte alla &FED; &SEL; FAQ</title>
<para>
Questa FAQ �� disponibile su <ulink
url="http://fedora.redhat.com/docs/selinux-faq-fc3/">http://fedora.redhat.com/docs/selinux-faq-fc3/</ulink>.
</para>
<para>
Per modifiche o aggiunte alle &FED; &SEL; FAQ, usate questo <ulink
url="&BUG-URL;">bugzilla template</ulink>, che precompila la maggior parte del
rapporto d'errore. Le patches dovranno essere un <command>diff -u</command> rispetto all'XML,
disponibile dal CVS (fate riferimento a <ulink
url="http://fedora.redhat.com/projects/docs/" /> per dettagli su come
ottenere il modulo fedora-docs/selinux-faq via CVS anonimo; puoi avere
solo il modulo <filename>fedors-docs/selinux-faq</filename> se non vuoi
l'intero albero <filename>fedora-dcs</filename>.) Altrimenti,
semplice testo che mostri prima e dopo �� sufficiente.
</para>
<para>
Per avere una lista di tutti i rapporti d'errore inerenti questa FAQ, fate riferimento a <ulink
url="https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=118757">https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=118757</ulink>.
</para>
</tip>
<qandaset defaultlabel="qanda" id="selinux-faq-list">
<?dbhtml toc="1"?>
<qandadiv id="faq-div-understanding-selinux">
<title>Comprendere &SEL;</title>
<qandaentry>
<question>
<para>
Cos'�� &SEL;?
</para>
</question>
<answer>
<para>
&SEL; (<firstterm>Security-Enhanced Linux</firstterm>) in &FC; ��
un implementazione del <firstterm>mandatory access
control</firstterm> nel kernel di Linux che usa il
<firstterm>Linux Security Modules</firstterm>
(<abbrev>LSM</abbrev>) framework. La sicurezza standard di Linux �� basata su un modello
definito come <firstterm>discretionary access control</firstterm>.
</para>
<itemizedlist>
<listitem>
<para>
Discretionary access control (<abbrev>DAC</abbrev>) —
questo �� il modello base della sicurezza di Linux, e non fornisce protezione
da software corrotto o malevolo eseguito come utente normale o
root. Gli utenti possono assegnare rischiosi livelli di accesso ai files
che possiedono.
</para>
</listitem>
<listitem>
<para>
Mandatory access control (<abbrev>MAC</abbrev>) — pieno
controllo su tutte le iterazioni del software. Policy definite
amministrativamente controllano da vicino le iterazioni fra utenti e processi
con il sistema, e forniscono protezione da software
corrotto o malevolo eseguito sotto qualsiasi utente.
</para>
</listitem>
</itemizedlist>
<para>
In un modello DAC, i file e le risorse decisionali sono basate solamente
sull'identit�� utente e il proprietario degli oggetti. Ogni utente e programma
eseguito da quell'utente ha completa discrezione sugli oggetti dell'utente.
Software malizioso o difettoso pu�� fare qualsiasi cosa con i files e
le risosrse controllate attraverso l'utente che ha avviato i processi.
Se l'utente �� il super-user o l'applicazione ��
<command>setuid</command> o <command>setgid</command> root,
il processo pu�� avere un livello di controllo root sull'intero file
system.
</para>
<para>
Un sistema MAC non soffre di questi problemi. Primo, puoi
definire-amministrativamente una policy di sicurezza su tutti i processi ed
oggetti. Secondo, puoi controllare tutti i processi e gli oggetti, nel
caso di &SEL; mediante il kernel. Terzo, le decisioni sono basate su
tutte le informazioni di sicurezza rilevanti disponibili, e non solo sulla
identit�� utente autenticata.
</para>
<para>
Il MAC sotto &SEL; permette di fornire permessi granulari per tutti i
<firstterm>soggetti</firstterm> (utenti, programmi, processi) ed
<firstterm>oggetti</firstterm> (files, devices). In pratica,
pensa ai soggetti come processi, ed gli oggetti come lo scopo di un
operazione di un processo. Puoi garantire con sicurezza ad un processo solo i
permessi che gli occorrono per eseguire la sua funzione, e niente di pi��.
</para>
<para>
L'implementazione di &SEL; usa un <firstterm>role-based access
control</firstterm> (<abbrev>RBAC</abbrev>), che fornisce
un astrazione di controllo a livello-utente basata su ruoli, e sui
<firstterm><trademark class="registered">Type
Enforcement</trademark></firstterm> (<abbrev>TE</abbrev>). TE
usa una tabella (matrice) per manipolare i controlli di accesso, applicando le regole
della policy basate sui tipi di processi ed oggetti. I tipi di processo
sono chiamati domini, ed un riferimento incrociato sulla matrice dei
domini dei processi e del tipo degli oggetti definisce la loro interazione.
Questo pu�� fornire un controllo estremamente granulare per gli attori in un sistema
Linux.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Cos'�� una policy &SEL;?
</para>
</question>
<answer>
<para>
La policy &SEL; descrive i permessi di accesso per tutti i soggetti
e gli oggetti, esempio, l'intero sistema degli utenti, programmi, e
processi ed i files ed i devices su cui agiscono. La policy di &FC; ��
contenuta in un pacchetto, con una pacchetto sorgente associato. Attualmente
i pacchetti che contengono le policy sono:
</para>
<itemizedlist>
<listitem>
<para><filename>selinux-policy-strict-<replaceable><version-arch></replaceable>.rpm</filename>
and
<filename>selinux-policy-strict-sources-<replaceable><version-arch></replaceable>.rpm</filename>
</para>
</listitem>
<listitem>
<para>
<filename>selinux-policy-targeted-<replaceable><version-arch></replaceable>.rpm</filename>
and
<filename>selinux-policy-targeted-sources-<replaceable><version-arch></replaceable>.rpm</filename>
</para>
</listitem>
</itemizedlist>
<para>
I sorgenti delle policy risiedono in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy</filename>,
quando sono installati, ed i files binari delle policy in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy</filename>.
Il sorgente delle policy non �� necessario per le installazioni ultra-minimali. La
policy per i tipi ed i domini �� configurata separatamente dal
contesto di sicurezza per i soggetti e gli oggetti.
</para>
</answer>
</qandaentry>
<qandaentry>
<!-- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133403 thanks to -->
<!-- dwalsh for supplying the source FAQs -->
<question>
<para>
Cos'�� la policy targeted di &SEL;?
</para>
</question>
<answer>
<para>
Inizialmente, quando &SEL; fu incluso in Fedora Core, la policy strict di NSA
fu applicata. A scopo di prova, ci�� aiut�� a trovare
centinaia di problemi nella strict policy. In seguito, �� divenne
ovvio che applicare una singola strict policy ai molti ambienti
degli utenti &FED; non era fattibile. Amministrare una singola
strict policy per qualsiasi cosa diversa dal'installazione standard
avrebbe richiesto un esperienza locale superiore.
</para>
<para>
A questo punto, gli sviluppatori &SEL; rividero le loro scelte, e
decisero di adottare una strategia differente. Fu deciso di creare una
policy che puntasse a bloccare specifici demoni, specialmente
quelli pi�� vulnerabili agli attacchi o pi�� devastanti per il sistema se corrotti o
compromessi. Al resto del sistema �� consentita l'esecuzione come fosse sotto
la sicurezza standard di Linux, esempio, funzionare lo stesso se &SEL; �� abilitato o meno.
</para>
<para>
Sotto la policy targeted, molti processi sono eseguiti nel
dominio <computeroutput>unconfined_t</computeroutput>. Come implica
il nome, questi processi non sono per lo pi�� confinati dalla
policy &SEL;. Questi sono comunque ancora governati dalla sicurezza
standard di Linux/UNIX.
</para>
<para>
Specifici demoni di rete hanno policy scritte per loro, e la
policy <computeroutput>unconfined_t</computeroutput> transita
su queste policies quando l'applicazione viene avviata. Per esempio, al
boot del sistema, <command>init</command> viene eseguito sotto la
policy <computeroutput>unconfined_t</computeroutput>, ma quando viene
avviato <command>named</command>, �� transitato sotto il dominio
<computeroutput>named_t</computeroutput> ed �� bloccato dalla policy appropriata.
</para>
<para>
Per maggiori informazioni sull'abilitazione e disabilitazione delle policy targeted
per ogni demone specifico, fate riferimento a <xref
linkend="using-s-c-securitylevel"/>.
</para>
</answer>
</qandaentry>
<qandaentry>
<!-- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133403 thanks to -->
<!-- dwalsh for supplying the source FAQs -->
<question>
<para>
Che demoni sono protetti dalla targeted policy?
</para>
</question>
<answer>
<para>
Attualmente, la lista dei demoni �� <command>dhcpd</command>,
<command>httpd</command> (<filename>apache.te</filename>),
<command>named</command>, <command>nscd</command>,
<command>ntpd</command>, <command>portmap</command>,
<command>snmpd</command>, <command>squid</command>, and
<command>syslogd</command>. I files di policy per questi demoni si
trovano in
<filename>/etc/selinux/targeted/src/policy/domains/program</filename>.
</para>
<para>
In futuro, molti demoni saranno aggiunti alla policy di protezione
targeted.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Che demoni aggiungerete alla targeted policy? Che ne dite
di Sendmail, Postfix, MySQL, o PostgreSQL?
</para>
</question>
<answer>
<para>
Gli sviluppatori di &SEL; vorrebbero aggiungere eventualmente ftp e gli agenti di
posta elettronica alla targeted policy. Ad esempio, <command>vsftpd</command> potrebbe
funzionare in modo simile a <command>login</command>: dopo il log-in, un nuovo processo �� eseguito sotto il contesto dell'utente (contesto utente reale o anonimo).
</para>
<para>
Un problema con gli agenti di posta elettronica �� che hanno spesso hanno bisogno di
manipolare files nelle home directory utente. Un obbiettivo della targeted policy
�� quello di evitare problemi di etichettatura nelle home directory degli utenti.
Ci si sta ancora lavorando su.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
E la policy strict? Funzioner�� comunque?
</para>
</question>
<answer>
<para>
La policy strict su &FC; <emphasis>funziona</emphasis>. La sfida ��
con gli ambienti unici di utenti differenti. Per farla funzionare
nel tuo ambiente, avrai bisogno di aggiustare sia la policy
che i tuoi sistemi.
</para>
<para>
Per aiutare a rendere semplice l'uso della strict policy, gli sviluppatori di &SEL;
hanno lavorato sul rendere il cambiamento da un policy all'altra
semplice. Per esempio,
<command>system-config-securitylevel</command> fa una rietichettatura
negli scripts di avvio.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Cosa sono i file contexts?
</para>
</question>
<answer>
<para>
I file contexts sono usati dal comando <command>setfiles</command>
per rendere persistenti le etichette che descrivono il contesto di sicurezza
per un file o una directory.
</para>
<para>
&FC; �� rilasciato con lo script <command>fixfiles</command> che
supporta tre opzioni: <option>check</option>,
<option>restore</option>, e <option>relabel</option>. Questo
permette agli utenti di rietichettare il file system senza aver installato il
pacchetto <filename>selinux-policy-targeted-sources</filename>.
L'uso della linea di comando �� molto pi�� amichevole rispetto
al comando <command>setfiles</command> standard.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come posso vedere il contesto di sicurezza di un file, un utente, o un processo?
</para>
</question>
<answer>
<para>
La nuova opzione <option>-Z</option> �� il metodo piu immediato per
mostrare il contesto di un soggetto o di un oggetto:
</para>
<screen>
<command>ls -alZ <replaceable>file.foo</replaceable>
id -Z
ps -eZ</command>
</screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Che differenza c'�� fra un <firstterm>dominio</firstterm> ed
un <firstterm>tipo</firstterm>?
</para>
</question>
<answer>
<para>
Non c'�� differenza fra un dominio ed un tipo, comunque
il dominio �� qualche volta usato per riferisi al tipo di un processo.
L'uso del dominio in questo modo discende dal tradizionale modello TE, dove
i domini ed i tipi sono separati.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-controlling-selinux">
<title>Controllare &SEL;</title>
<qandaentry>
<question>
<para>
Come installo o non installo &SEL;?
</para>
</question>
<answer>
<para>
Il programma di installazione si comporta basandosi sulle scelte che fai nella
schermata di <guilabel>Configurazione del Firewall</guilabel>. Di base
la policy applicata �� la targeted, che per scelta predefinita �� attiva.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come cambio la policy che sto usando?
</para>
</question>
<answer>
<caution>
<title>Cambiare policy non �� una cosa da prendere alla leggera.</title>
<para>
A meno che tu non stia provando una nuova policy su una macchina test a
scopo di ricerca, dovresti seriamente considerare la situazione
prima di cambiare policy su un sistema in produzione.
</para>
<para>
Il modo di cambiare policy �� semplice. Questo �� un metodo abbastanza
sicuro, ma deve prima essere provato su un sistema test.
</para>
</caution>
<para>
Un metodo �� quello di usare
<command>system-config-securitylevel</command> per cambiare la
policy e impostare il filesystem da rietichettare.
</para>
<para>
La seguente �� la procedura manuale:
</para>
<procedure>
<step>
<para>
Edita <filename>/etc/selinux/config</filename> e cambia il
tipp di policy in
<computeroutput>SELINUXTYPE=<replaceable>policyname</replaceable></computeroutput>.
</para>
</step>
<step>
<para>
Per essere sicuri che tu possa avere un sistema funzionante dopo un reboot, setta
il modo a <computeroutput>SELINUX=permissive</computeroutput>. In questo modo
SELinux sar�� eseguito sotto la corretta policy, ma ti permetter�� di fare
il login se c'�� qualche problema, tipo il contesto di un file non correttamente
etichettato.
</para>
</step>
<step>
<para>
Di agli init scripts di rietichettare il sistema al riavvio con il
comando <command>touch /.autorelabel</command>.
</para>
</step>
<step>
<para>
Riavvia il sistema. Un riavvio pulito sotto la nuova policy
permetter�� a tutti i processi del sistema di avviarsi nel contesto
appropriato, e rivelare qualsiasi problema nel cambiamento di policy.
</para>
</step>
<step>
<para>
Conferma che i tuoi cambiamenti abbiano effetto con il comando
<command>sestatus -v</command>. Con il nuovo sistema avviato
in modalit�� <computeroutput>permissive</computeroutput>, controlla
<filename>/var/log/messages</filename> per i messaggi
<computeroutput>avc: denied</computeroutput>. Questi
possono indicare un problema che deve essere risolto affinch�� il sistema
possa funzionare senza difficolt�� sotto la nuova policy.
</para>
</step>
<step>
<para>
Quando sei soddisfatto che il sistema sia stabile sotto la
nuova policy, abilita l'enforcing cambiando
<computeroutput>SELINUX=enforcing</computeroutput>. Puoi
sia riavviare che eseguire <command>setenforce 1</command> per passare
in enforcing in tempo reale.
</para>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come eseguo il back up dei files da un file system &SEL;?
</para>
</question>
<answer>
<para>
Puoi usare l'utilit�� <command>star</command>, che supporta
gli attributi estesi che contengono le etichette dei contesti di sicurezza.
Specifica il formato <option>-xattr</option> e <option>exustar</option>
quando creai gli archivi.
</para>
<screen>
<command>ls -Z /var/log/maillog</command>
-rw------- root root system_u:object_r:var_log_t /var/log/maillog
<command>cd /var/log
star -xattr -H=exustar -c -f maillog.star ./maillog*</command>
</screen>
<caution>
<title>I percorsi assoluti possono sovrascrivere i dati esistenti</title>
<para>
Se usi un percorso assoluto, come
<filename>/var/log/maillog</filename>, quando decompatti l'archivio
con <command>star -c
-f</command>, i files verranno ripristinati nello stesso percorso in
cui erano stati archiviati. Il file <filename>maillog</filename> tenter��
di scriverli in <filename>/var/log/maillog</filename>. Potresti
ricevere un avviso da <command>star</command> se i
files che stanno per essere sovrascritti hanno una data pi�� recente, ma non potrai
contare su questo comportamento.
</para>
<para>
Considera attentamente come costruire gli argomenti d'archiviazione.
</para>
</caution>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come posso installare la policy strict per default con il kickstart?
</para>
</question>
<answer>
<procedure>
<step>
<para>
Sotto la sezione <computeroutput>%packages</computeroutput>,
aggiungete <filename>selinux-policy-strict</filename>.
</para>
</step>
<step>
<para>
Sotto la sezione <computeroutput>%post</computeroutput>,
aggiungete quanto segue:
</para>
<screen>
<computeroutput>lokkit -q --selinuxtype=strict
touch /.autorelabel</computeroutput>
</screen>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry id="using-s-c-securitylevel" xreflabel="How to use system-config-securitylevel">
<question>
<para>
Come abilito/disabilito la protezione &SEL; per uno specifico demone sotto
la policy targeted?
</para>
</question>
<answer>
<para>
Usa <command>system-config-securitylevel</command> per controllare i
valori Booleani di specifici demoni. Per esempio, se ritieni
di aver bisogno di sisabilitare &SEL; per Apache per eseguirlo correttamente nel tuo
ambiente, puoi disabilitare il valore in
<command>system-config-securitylevel</command>. Questo disattiva la
transizione della policy definita in
<filename>apache.te</filename>, lasciando rimanere <command>httpd</command>
sotto la regolare sicurezza Linux.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come faccio funzionare una directory utente <filename>public_html</filename>
sotto &SEL;?
</para>
</question>
<answer>
<para>
Questo processo presume che hai abilitato le directories HTML pubbliche per gli utenti
nella configurazione HTTP di Apache
(<filename>/etc/httpd/conf/httpd.conf</filename>). Questo processo
copre solo il servizio di contenuti Web statici. Per maggiori informazioni
su &APACHE; e &SEL;, riferitevi a <ulink
url="http://fedora.redhat.com/docs/selinux-apache-fc3/" />.
</para>
<procedure>
<step>
<para>
Se non l'hai gi��, avrai necessit�� di creare la
directory <filename>public_html</filename> e popolarla con
i files e le cartelle che dovranno essere servite.
</para>
<screen>
<command>cd ~
mkdir public_html
cp /path/to/content ~/public_html</command>
</screen>
</step>
<step>
<para>
A questo punto, <command>httpd</command> �� configurato per servire
i contenuti, ma tu continuerai a ricevere un errore <computeroutput>403
forbidden</computeroutput>. Questo poich�� ad
<command>httpd</command> non �� consentito di leggere i tipi
di sicurezza per le directory ed i files che vengono creati nelle
directory home degli utenti. Per risolvere questo, cambiate i contesti
di sicurezza della cartella e dei suoi contenuti ricursivamente usando
l'opzione <option>-R</option>:
</para>
<screen>
<command>ls -Z -d public_html/</command>
<computeroutput>drwxrwxr-x auser auser user_u:object_r:user_home_t public_html</computeroutput>
<command>chcon -R -t httpd_user_content_t public_html/
ls -Z -d public_html/</command>
<computeroutput>drwxrwxr-x auser auser user_u:object_r:httpd_user_content_t public_html/</computeroutput>
<command>ls -Z public_html/</command>
<computeroutput>-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t bar.html
-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t baz.html
-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t foo.html</computeroutput>
</screen>
<para>
Potrai notare qualche tempo dopo che il campo user, impostato
a <computeroutput>user_u</computeroutput>, �� cambiato in
<computeroutput>system_u</computeroutput>. Ci�� non
avr�� effetto su come funziona la policy targeted; il campo che conta
�� il campo tipo.
</para>
</step>
<step>
<para>
Adesso sarai in grado di servire pagine web statiche. Se
continuerai ad avere errori, controlla di vedere che la Booleana che
abilita le home directories utente sia abilitata. Questo pu�� essere impostato
usando <application>system-config-securitylevel</application>,
sotto il tab <guilabel>&SEL;</guilabel> all'interno dell'area <guilabel>Modifica la
Policy &SEL;</guilabel>, abilitando <computeroutput>Permetti
ad HTTPD di leggere le home directories</computeroutput>. I cambiamenti avranno
effetto immediato.
</para>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come disabilito &SEL; all'avvio?
</para>
</question>
<answer>
<para>
Aggiungi <option>selinux=0</option> alla linea di comando del tuo kernel.
</para>
<caution>
<title>Sta attento quando disabiliti &SEL;</title>
<para>
Sta veramente attento nell'usare questa opzione. Se esegui l'avvio con
<option>selinux=0</option>, ogni file che hai creato mentre &SEL; ��
disabilitato non avr�� le informazioni di contesto &SEL;. Dovrai come minimo
rietichettare il file system, ed �� possibile che
non sarai in grado di avviare il sistema con <option>selinux=1</option>,
necessitando un avvio in modalit�� single-user per il ripristino.
</para>
<para>
Come alternativa a <option>selinux=0</option>, prova ad usare
<computeroutput>SELINUX=disabled</computeroutput> in
<filename>/etc/selinux/config</filename>.
</para>
</caution>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come pongo l'enforcing on/off all'avvio?
</para>
</question>
<answer>
<para>
Puoi specificare la modalit�� &SEL; usando il file di configurazione
<filename>/etc/sysconfig/selinux</filename>.
</para>
<screen>
<computeroutput># This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=<replaceable>enforcing</replaceable>
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=<replaceable>targeted</replaceable>
</computeroutput>
</screen>
<para>
Impostando il valore su <computeroutput>enforcing</computeroutput> ��
uguale ad aggiungere <option>enforcing=1</option> alla linea di comando
quando avvii il kernel per attivare l'enforcing, mentre impostando
il valore su <computeroutput>permissive</computeroutput> �� come
aggiungere <option>enforcing=0</option> per disattivare l'enforcing.
Nota che il <emphasis role="bold">parametro della linea di comando del kernel
prevarica il file di configurazione</emphasis>.
</para>
<para>
Comunque, impostare il valore su
<computeroutput>disabled</computeroutput> non �� lo stesso di
<option>selinux=0</option> nel parametro di avvio del kernel. Invece di
disabilitare pienamente &SEL; nel kernel, l'impostazione
<computeroutput>disabled</computeroutput> disabilita l'enforcing
e salta il caricamento della policy.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come disabilito temporaneamente la modalit�� di enforcing senza dover
riavviare?
</para>
</question>
<answer>
<para>
Questa situazione solitamente insorge quando non puoi eseguire un operazione
che viene prevenuta dalla policy. Esegui il comando
<command>setenforce 0</command> per disabilitare la modalit�� di enforcing in
tempo reale. Quando hai terminato, esegui <command>setenforce 1</command>
per riattivare l'enforcing.
</para>
<note>
<title>E' richiesto il ruolo <computeroutput>sysadm_r</computeroutput></title>
<para>
Devi lanciare il comando <command>setenforce</command> con
il ruolo <computeroutput>sysadm_r</computeroutput>; per farlo,
usa il comando <command>newrole</command>. Alternativamente, se
cambi su root usando <command>su -</command>, otterrai il ruolo
<computeroutput>sysadm_r</computeroutput> automaticamente.
</para>
</note>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come pongo l'auditing alle system-call on/off all'avvio?
</para>
</question>
<answer>
<para>
Aggiungi <option>audit=1</option> alla linea di comando del kernel per attivare
l'auditing alle system-call. Aggiungi <option>audit=0</option> alla
linea di comando del kernel per disattivare l'auditing alle system-call.
</para>
<para>
L'auditing alle system-call �� disattivato per impostazione predefinita. Quando �� attivato,
fornisce informazioni sulle system-call che erano in esecuzione quando SELinux
genera un messaggio <computeroutput>denied</computeroutput>. Questo
pu�� essere d'aiuto quando fai il debugging della policy.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come disabilito temporaneamente l'auditing alle system-call senza dover
riavviare?
</para>
</question>
<answer>
<para>
Questa opzione al momento non �� supportata. In futuro, verr�� fornita un utilit��
per amministrare l'auditing.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come ottengo informazioni sullo status della mia installazione &SEL;?
</para>
</question>
<answer>
<para>
Come root, esegui il comando <command>/usr/sbin/sestatus
-v</command>. Per maggiori informazioni, fa riferimento alla
pagina di manuale di
<filename>sestatus(8)</filename>.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-resolving-problems">
<title>Risoluzione dei problemi</title>
<qandaentry>
<question>
<para>
La mia applicazione non funziona come mi aspettavo e sto vedendo
dei messaggi <computeroutput>avc: denied</computeroutput>, come
risolvo?
</para>
</question>
<answer>
<para>
Questo messaggio vuol dire che l'attuale policy SELinux non permette
all'applicazione di fare qualcosa. C'�� un numero di ragioni
per cui ci�� pu�� succedere.
</para>
<para>
Primo, uno dei files a cui l'applicazione prova ad accedere potrebbe
essere etichettato male. Se il messaggio AVC si riferisce ad un file specifico,
controlla la sua etichetta corrente con <command>ls -alZ
<replaceable>/path/to/file</replaceable></command>. Se vi sembra
sbagliata, potrete provare ad usare <command>restorecon -v
<replaceable>/path/to/file</replaceable></command>. Se hai
un gran numero di dinieghi relativi a files, potresti voler usare
<command>fixfiles relabel</command>, o eseguire
<command>restorecon</command> con l'opzione <option>-R</option>
per rietichettare recursivamente il percorso di una directory.
</para>
<para>
Altre volte, i dinieghi possono essere dovuti ad un cambiamento nella
configurazione del programma non ammesso dalla policy. Per esempio, se
vuoi far si che Apache ascolti anche sulla port 8800, questo richieder�� un
cambiamento nella policy di sicurezza, <filename>apache.te</filename>. Vedi
<xref linkend="external-link-list"/> per maggiori informazioni sulla
scrittura delle policy.
</para>
<para>
Se hai difficolt�� nel far funzionare un'applicazione specifica
come Apache, vedi <xref linkend="using-s-c-securitylevel"/>
to work, see <xref linkend="using-s-c-securitylevel"/> per
sapere come disabilitare l'enforcement solo per quell'applicazione.
</para>
</answer>
</qandaentry>
<!-- <qandaentry>
<question>
<para>
I'm trying to upgrade from &FC; &FCVER; to &FC; &LOCALVER;, and
the installer keeps crashing with an &SEL; error.
</para>
</question>
<answer>
<para>
This occurs because Anaconda finds an existing
<filename>/selinux</filename> directory. This problem has been
fixed in the latest version of the installer.
</para>
<para>
To work around this bug, either remove the directory just prior to
upgrading, <command>rm -rf /selinux</command>, or during an
install, switch to tty2 before packages start being upgraded, and
do <command>rm -rf /mnt/sysimage/selinux</command>.
</para>
</answer>
</qandaentry>
-->
<qandaentry>
<question>
<para>
Ho installato &FC; su un sistema con una partizione
<filename>/home</filename> gi�� esistente, ed ora non posso fare il log in.
</para>
</question>
<answer>
<para>
La tua partizione <filename>/home</filename> non �� etichettata
correttamente. Puoi facilmente risolvere questo problema in due modi.
</para>
<para>
Se vuoi solamente rietichettare <filename>/home</filename>
ricorsivamente:
</para>
<screen>
<command>/sbin/restorecon -v -R /home</command>
</screen>
<para>
Se vuoi essere sicuro che non ci siano altri files non correttamente
rietichettati, puoi rietichettare l'intero filesystem:
</para>
<screen>
<command>/sbin/fixfiles relabel</command>
</screen>
<para>
Dovrai avere installato il pacchetto <filename>policycoreutils</filename>
per usare <command>fixfiles</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Dopo aver rietichettato la mia <filename>/home</filename> usando
<command>setfiles</command> o <command>fixfiles</command>, sar��
ancora in grado di leggere <filename>/home</filename> con un
sistema con &SEL; non abilitato?
</para>
</question>
<answer>
<para>
Puoi leggere i files da una distribuzione senza &SEL;, o una con
&SEL; disabilitato. Comunque, i files creati dal sistema privo di &SEL;
non avranno un contesto di sicurezza, nemmeno l'avr�� qualsiasi files che
rimuoverai e ricreerai. Questo potrebbe essere un problema con files tipo
<filename>~/.bashrc</filename>. Dovrai rietichettare la tua
<filename>/home</filename> quando ritornerai a &FC;.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come posso condividere directories usando NFS tra &FC; e sistemi
non-&SEL;
</para>
</question>
<answer>
<para>
NFS supporta in modo trasparente molti tipi di file system, e pu��
essere usato per condividere directories tra sistemi &SEL; e non-&SEL;.
</para>
<para>
Quando monti un file system non-&SEL; via NFS, per impostazione predefinita &SEL;
tratter�� tutti i files nella condivisione come avessero contesto
<computeroutput>nfs_t</computeroutput>. Potrai prevaricare il contesto predefinito
impostandolo manualmente usando l'opzione
<option>context=</option>. Ad esempio, questo far��
apparire i files nella directory NFS montata con un contesto di
<computeroutput>system_u:object_r:tmp_t</computeroutput> in &SEL;:
</para>
<screen>
<command>mount -t nfs -o context=system_u:object_r:tmp_t server:/shared/foo /mnt/foo</command>
</screen>
<para>
Quando &SEL; esporta un file system via NFS, i files creati avranno
il contesto della directory dove sono stati creati. In altre
parole, la presenza di &SEL; sul sistema remoto che ha montato la condivisione non ha
effetto sui contesti di sicurezza locali.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come posso creare un nuovo account utente Linux con la home directory utente
avente il contesto appropriato?
</para>
</question>
<answer>
<!-- wtf was I trying to say here?
<para>
This depends on the policy you are running. A very restrictive
policy requires you to change
</para>
-->
<para>
Puoi creare il nuovo utente con il comando standard
<command>useradd</command>. Prima dovrai diventare root;
sotto la policy strict avrai bisogno di cambiare al ruolo
<computeroutput>sysadm_r</computeroutput>. Questo cambio di contesto
�� stato incorporato nel comando <command>su</command> ed
avviene automaticamente. Per la policy targeted, non avrai bisogno
di cambiare ruolo, rimanendo in
<computeroutput>unconfined_t</computeroutput>:
</para>
<screen>
<command>su - root
id -Z
root:system_r:unconfined_t
useradd auser
ls -Z /home
drwx------ auser auser root:object_r:user_home_dir_t /home/auser</command>
</screen>
<para>
Il contesto iniziale per una nuova directory utente ha un identit�� di
<computeroutput>root</computeroutput>. In seguinto la rietichettatura del
file system cambier�� l'identit�� a
<computeroutput>system_u</computeroutput>. Queste sono funzionalmente
le stesse poich�� il ruolo ed il tipo sono identici
(<computeroutput>object_r:user_home_dir_t</computeroutput>.)
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Tutte le altre documentazioni su &SEL; affermano che il
comando <command>su</command> cambier�� solamente l'identit�� Linux
e <emphasis>non</emphasis> il ruolo di sicurezza.
</para>
</question>
<answer>
<para>
Il team di sviluppo di &FC; ha preso una direzione leggermente differente
rispetto alla pratica di &SEL; esistente. Le transizioni del contesto di sicurzza adesso
sono integrate in <command>su</command> via
<computeroutput>pam_selinux</computeroutput>. Questo semplifica
enormemente l'uso del sistema.
</para>
<para>
In pratica, �� come combinare il tradizionale
<command>su</command> con il <command>newrole</command> di &SEL;,
in un singolo passo invece di due.
</para>
<para>
Altre forme di cambio d'identit�� di Linux/<trademark
class="registered">UNIX</trademark>, per esempio
<command>setuid(2)</command>, non causano un cambio d'identit��
&SEL;.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Sto avendo alcune difficolt�� con errori <command>avc</command> che riempiono
i miei logs per un programma in particolare. Come scelgo escluderne l'audit
d'accesso?
</para>
</question>
<answer>
<para>
Per esempio, se volevi escludere l'audit di <command>dmesg</command>,
potresti inserire questa riga nel tuo file
<filename>/etc/selinux/targeted/src/policy/dmesg.te</filename>
</para>
<screen>
<computeroutput>dontaudit dmesg_t userdomain:fd { use };</computeroutput>
</screen>
<para>
Questo eliminer�� l'output d'errore dal terminale per tutti
gli userdomains (<varname>user</varname>, <varname>staff</varname> e
<varname>sysadm</varname>).
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Anche avviando in modalit�� permissive, ho un gran numero di
messaggi <computeroutput>avc denied</computeroutput>.
</para>
</question>
<answer>
<para>
In modalit�� non-enforcing, avrai
<emphasis>pi��</emphasis> messaggi che in modalit�� enforcing. Ci��
avviene poich�� il kernel sta loggando ogni diniego di accesso come fossi
in modalit�� enforcing. Siccome non hai restrizioni, puoi
fare pi�� cose, che danno come risultato pi�� log di
diniego.
</para>
<para>
Per esempio, se un applicazione eseguita sotto la modalit�� enforcing ha
il divieto provare a leggere un certo numero di files in una directory, essa
verr�� fermata all'inizio dell'azione. In
modalit�� non-enforcing, l'applicazione non viene fermata dal traversare
l'albero della directory, e ricever�� un messaggio di diniego per ogni
file letto nella directory.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Ho un particolare diniego di premesso solo quando &SEL; �� in modalit��
enforcing, ma non vedo nessun messaggio di audit in
<filename>/var/log/messages</filename>. Come posso identificare la
causa di questi dinieghi silenziosi?
</para>
</question>
<answer>
<para>
La ragione pi�� comune per un diniego silenzioso �� quando la policy
contiene un esplicita regola di <computeroutput>dontaudit</computeroutput>
per sopprimere i messaggi di audit. La
regola di <computeroutput>dontaudit</computeroutput> �� spesso usata
quando un segnale di diniego benigno riempie gli audit logs.
</para>
<para>
Per vedere il tuo particolare diniego, dovrai abilitare
l'auditing di tutte le regole <computeroutput>dontaudit</computeroutput>:
</para>
<screen>
<command>cd /etc/selinux/targeted/src/policy
make enableaudit
make load</command>
</screen>
<caution>
<title>Abilitare l'output di <computeroutput>dontaudit</computeroutput>
�� verboso</title>
<para>
Abilitare l'auditing di tutte
le regole <computeroutput>dontaudit</computeroutput> produrr��
un gran numero di informazioni audit, molte delle quali
irrilevanti per il tuo diniego.
</para>
<para>
Usa questa tecnica solo se stai cercando un
messaggio di diniego che sembra avvenire silenziosamente.
Probabilmente desidererai ri-abilitare
le regole <computeroutput>dontaudit</computeroutput> il pi�� presto
possibile.
</para>
</caution>
<para>
Per ri-abilitare le regole <computeroutput>dontaudit</computeroutput>,
fai cos��:
</para>
<screen>
<command>cd /etc/selinux/targeted/src/policy
make clean
make load</command>
</screen>
<!-- commented out just in case it needs to be rewritten and included:
<para>
Another reason for getting silent denials is on an
<function>exec</function> when a domain transition would
normally occur, but the new domain is not authorized for
the current role.
</para>
<para>
At present, these errors are only logged when &SEL; is
running in permissive mode. This has been fixed in the
upstream Linux kernel so that it will log an audit message.
The current &FC; test kernel does not yet include this
change.
</para>
from ssmalley:
The Fedora kernel now includes the change, so the transition failures
now show up as security_compute_sid messages (also handled via the audit
framework). Example message below for a policy that failed to authorize
sysadm_r for system_chkpwd_t (an error from an earlier policy that has
been fixed):
audit(1083674459.837:0): security_compute_sid: invalid context root:sysadm_r:system_chkpwd_t for scontext=root:sysadm_r:newrole_t tcontext=system_u:object_r:chkpwd_exec_t tclass=process
-->
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Perch�� non vedo l'output quando eseguo certi demoni in modalit��
debug o interattiva?
</para>
</question>
<answer>
<para>
&SEL; disabilita intenzionalmente l'accesso ai dispositivi tty per impedire
ai demoni la comunicazione verso il terminale di controllo.
Questa comunicazione �� un potenziale buco nella sicurezza poich�� questi
demoni possono inserire comandi nei terminali di controllo. Un
programma bacato o compromesso potrebbe causare seri problemi con
questo.
</para>
<para>
Ci sono alcuni modi per permetterti di catturare lo STDOUT da questi demoni. Un
metodo �� quello di eseguire il pipe dell'output al comando cat.
</para>
<screen>
<command>snmpd -v | cat</command>
</screen>
<para>
Quando fai il debug di un demone, potresti voler disattivare la transizione
del demone al suo dominio specifico. Puoi farlo usando
<application>system-config-securitylevel</application> o
<command>setsebool</command> dalla linea di comando.
</para>
<para>
Un opzione finale �� quella di disattivare la modalit�� di enforcing durante il debug.
Puoi farlo con <command>setenforce 0</command>, usando
<command>setenforce 1</command> per ri-abilitare &SEL; quando hai
terminato il debug.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Quando eseguo un upgrade del pacchetto delle policy (per esempio, usando
<command>yum</command>), cosa succede con la policy; ��
automaticamente aggiornata?
</para>
</question>
<answer>
<para>
Le policy si ricaricano da sole quando il pacchetto �� aggiornato. Questo sostituisce
il comando manuale <command>make load</command>.
</para>
<para>
In certe situazioni, pu�� essere necessario rietichettare il file
system. Questo potrebbe accadere per fissare gli errori di &SEL; qualora i
contesti dei files divenissero invalidi, o quando l'update della policy
fa dei cambiamenti ai <varname>file_contexts</varname>.
</para>
<para>
Dopo aver rietichettato il filesystem, un <command>reboot</command> non
�� necessario, ma �� utile per assicurare che ogni processo e programma
sia eseguito nel dominio appropriato. Questo �� altamente dipendente dai
cambiamenti nella policy aggiornata.
</para>
<para>
Se hai installato i pacchetti sorgente delle policy, es.
<filename>selinux-policy-strict</filename>, puoi eseguire questi
comandi per rietichettare il file system.
</para>
<screen>
<command>cd /etc/selinux/targeted/src/policy
make
make relabel
reboot</command>
</screen>
<para>
Se non stai usando i sorgenti delle policy, un altro approccio �� usare il
comando <command>fixfiles</command> o avvantaggiarsi del
meccanismo <filename>/.autorelabel</filename>:
</para>
<screen>
<command>fixfiles relabel
reboot</command>
</screen>
<screen>
<command>touch /.autorelabel
reboot</command>
</screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Se la policy rilasciata con il pacchetto di un applicazione cambia in
modo da richiedere la rietichettatura, potr�� RPM gestire la rietichettatura dei files
posseduti dal pacchetto?
</para>
</question>
<answer>
<para>
Si. I contesti di sicurezza per i files posseduti dal pacchetto sono
immagazzinati nei dati dell'header del pacchetto. I contesti dei files
sono impostati direttamente dopo la copia <command>cpio</command>, appena i
files del pacchetto sono poggiati sul disco.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Che relazioni intercorrono fra il pacchetto policy e policy
source?
</para>
</question>
<answer>
<!--
thanks to "Gene C." <czar czarc net> for authoring the
original answer in
http://www.redhat.com/archives/fedora-test-list/2004-April/msg00755.html
-->
<para>
Un pacchetto policy come
<filename>selinux-policy-targeted</filename> �� un requisito per
un installazione &SEL; funzionante, mentre un pacchetto sorgente come
<filename>selinux-policy-targeted-sources</filename> ��
richiesto se vuoi modificare la policy predefinita.
</para>
<para>
Il pacchetto policy ha i files minimi necessari per definire
la policy di sicurezza di &SEL;. Viene tenuto di ridotte dimensioni
per avere minimi requisiti di installazione.
</para>
<para>
Il pacchetto dei sorgenti della policy contiene le definizioni sorgente in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy</filename>
che sono richiesti per creare i files
<filename>/etc/selinux/<replaceable>policyname</replaceable>/contexts/*</filename>
e
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy/policy.<replaceable>version</replaceable></filename>.
<replaceable>version</replaceable> �� il numero di versione della
policy.
</para>
<para>
La scelta di quali pacchetti installare �� basata sul tipo di
installazione. Se intendi usare solo la configurazione di sicurezza predefinita
dagli sviluppatori &FC;, avrai bisogno solo del pacchetto
policy. Se vorrai adattare la tua policy di sicurezza in qualsiasi
modo, o vorrai eseguire <command>setools</command>, avrai bisogno
di installare il pacchetto di sorgenti della policy.
</para>
<para>
Installando o aggiornando i pacchetti della policy, la nuova policy
verr�� caricata non appena intallati i nuovi files. In modo analogo, installando o aggiornando il
pacchetto di sorgenti della policy ricreer�� sia il file
<filename>policy.<replaceable>version</replaceable></filename>
che il file <filename>file_contexts</filename>, quindi
verranno ricaricati come policy attuale effettiva.
</para>
<!-- not sure if currently still an issue, or how to rephrase
<caution>
<title>Caution</title>
<para>
If you have locally modified any of the policy sources, you want to be cautious about updating <filename>policy</filename> or <filename>policy-sources</filename>. Make
updating policy and/or policy-sources can have
interesting (but not particularly desirable)
effects. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118604
</para>
</caution>
-->
</answer>
</qandaentry>
<qandaentry>
<!--
http://www.redhat.com/archives/fedora-selinux-list/2004-May/msg00061.html
-->
<question>
<para>
Perch�� i files
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy/policy.<<replaceable>version</replaceable>></filename>
e
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/policy.<<replaceable>version</replaceable>></filename>
sono differenti (sizes, md5sums, dates)?
</para>
</question>
<answer>
<para>
Quando installi un pacchetto policy, i files binari pre-compilati della policy
sono inseriti direttamente in <filename>/etc/selinux</filename>.
Quando un pacchetto sorgente policy �� installato o aggiornato, i files binari
della policy vengono compilati in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy</filename>,
quindi spostati in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy/</filename>.
I differenti ambienti di compilazione creeranno files finali che hanno
differenti dimensioni, md5sums, e date.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
I nuovi pacchetti policy potranno disabilitere il mio sistema?
</para>
</question>
<answer>
<para>
C'�� la possibilit�� che cambiamenti nei pacchetti della policy o nella
policy rilasciata con un pacchetto applicativo possano causare errori,
pi�� dinieghi, o altri comportamenti sconosciuti. Per rimediare, puoi
scoprire quale pacchetto causa il problema ripristinando policy e pacchetti
applicativi uno alla volta. Se non vuoi tornare
ad una pacchetto precedente, i files di configurazione della vecchia
versione sono salvati con l'estensione di <filename>.rpmsave</filename>.
Assicurati di consultare le mailing lists, bugzilla, ed IRC per aiutarti
ad uscire dal problema. Se sei capace, scrivi un fix o una policy
per risolvere il problema.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come posso aiutare a scrivere una policy?
</para>
</question>
<answer>
<para>
Il tuo aiuto �� apprezzato infinitamente. Puoi cominciare entrando a far parte della
&SEL; mailing list, <ulink
url="mailto:fedora-selinux-list@redhat.com">fedora-selinux-list(a)redhat.com</ulink>;
puoi sottoscriverti e leggere gli archivi su <ulink
url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list">http://www.redhat.com/mailman/listinfo/fedora-selinux-list</ulink>.
Le FAQ non ufficiali hanno qualche informazione generica su come scrivere
le policy (<ulink
url="http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21...">http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21...</ulink>).
Un'altra nuova risorsa �� il Writing SE Linux policy HOWTO (<ulink
url="https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=2...">https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=2...</ulink>).
</para>
<para>
Il meglio su cui puoi scommettere �� dare un occhiata ai files di policy in <filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy/</filename>
e provare a sperimentare. Osserva i messaggi <computeroutput>avc
denied</computeroutput> in <filename>/var/log/messages</filename> per avere degli indizzi.
</para>
<para>
Uno strumento utile per uno scrittore di policy ��
<command>/usr/bin/audit2allow</command>, che traduce
i messaggi <computeroutput>avc</computeroutput> provenienti da
<filename>/var/log/messages</filename> in regole che possono essere usate
da &SEL;. Queste regole dovranno ovviamente essere rifinite.
</para>
<para>
Il comando <command>audit2allow</command> pu�� ricevere l'input con
tre metodi. Il metodo predefinito �� dallo standard input
(<firstterm>STDIN</firstterm>). Usando l'opzione <option>-i</option>
legge l'input da <filename>/var/log/messages</filename>,
e con l'opzione <option>-d</option> legge l'input dall'output
di <command>dmesg</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
La mia console �� inondata da messaggi, come li fermo?
</para>
</question>
<answer>
<para>
Per riottenere il controllo, disattiva i messaggi del kernel nella console
usando <command>dmesg -n 1</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Posso provare la policy predefinita senza installare il pacchetto
di sorgenti della policy?
</para>
</question>
<answer>
<para>
Puoi provare la policy predefinita di &SEL; installando solamente
i pacchetti <filename>selinux-policy-<replaceable>policyname</replaceable></filename>
e <filename>policycoreutils</filename>. Senza il
pacchetto dei sorgenti della policy installato, il comando <command>fixfiles</command>
automatizzer�� la rietichettatura del file system.
</para>
<para>
Il comando <command>fixfiles relabel</command> �� l'equivalente
di <command>make relabel</command>. Durante la rietichettatura,
canceller�� tutti i files in <filename>/tmp</filename>,
ripulendo i files che potrebbero avere vecchie etichette di contesto.
</para>
<para>
Altri comandi sono <command>fixfiles check</command>, che controlla
i files con etichette errate, e <command>fixfiles restore</command>,
che fissa i files mal etichettati ma non cancella i files in
<filename>/tmp</filename>. <command>fixfiles</command> non
accetta una lista di directories come argomento, il suo scopo ��
rietichettare l'intero filesystem. Se hai bisogno di rietichettare
un percorso specifico di directory, usa <command>restorecon</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Sto avendo difficolt�� nel far funzionare un applicazione KDE sotto &SEL;.
</para>
</question>
<answer>
<para>
Gli eseguibili KDE appaiono sempre come <command>kdeinit</command>, che
limita ci�� che pu�� essere fatto con la policy di &SEL;. Questo perch�� ogni
applicazione KDE viene eseguita nel dominio per <command>kdeinit</command>.
</para>
<para>
I problemi spesso vengono fuorui quando si installa &SEL; perch�� non ��
possibile rietichettare <filename>/tmp</filename> e
<filename>/var/tmp</filename>. Non c'�� un buon metodo di
determinare quale file dovrebbe avere quale contesto.
</para>
<para>
La soluzione �� quella di eseguire un pieno log out da KDE e rimuovere tutti i files
temporanei di KDE:
</para>
<screen>
<command>rm -rf /var/tmp/kdecache-<replaceable><username></replaceable>
rm -rf /var/tmp/<replaceable><other_kde_files></replaceable></command>
</screen>
<para>
Al prossimo login, il problema dovrebbe essere risolto.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Perch�� <computeroutput>SELINUX=disabled</computeroutput> non
funziona per me?
</para>
</question>
<answer>
<para>
Fa attenzione agli spazi vuoti nel file
<filename>/etc/sysconfig/selinux</filename>. Il codice �� molto
sensibile agli spazi vuoti, anche ai tabulatori.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-deploying-selinux">
<title>Implementare &SEL;</title>
<qandaentry>
<question>
<para>
Che file systems posso usare per &SEL;?
</para>
</question>
<answer>
<para>
Il file system deve supportare le estichette
<computeroutput>xattr</computeroutput> nel giusto
namespace <parameter>security.*</parameter>. Oltre a
ext2/ext3, XFS ha recentemente aggiunto il supporto per le necessarie
etichette.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Come incide &SEL; sulle prestazioni del sistema?
</para>
</question>
<answer>
<para>
Questa �� una variabile difficile da quantificare, ed �� pesantemente
dipendente dalla grandezza del sistema su cui &SEL; sta girando. L'ultima
volta che le prestazioni sono state misurate, l'incidenza era circa del 7% per
codice completamente non raffinato. I cambiamenti da allora sembrerebbero essere
peggiorati in alcuni casi, tipo nel networking. Le performance
e l'affinamento di SELinux sono una priorit�� del team di sviluppo.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Di che tipo di implementazioni/applicazioni/systemi, etc. dovr�� tener conto
per l'uso con &SEL;?
</para>
</question>
<answer>
<para>
Inizialmente, &SEL; servir�� ai server affacciati su Internet che eseguono
poche, funzioni specializzate, dove �� critico mantenere
una sicurezza estremamente stretta. Una simile macchina �� tipicamente
priva di software extra e servizi, ed esegue un servizio
molto mirato od un gruppo di servizi, come un Web server o un mail
server.
</para>
<para>
In questi servers di nicchia, potrai bloccare la policy molto strettamente.
Questo sar�� facilitato dal piccolo numero di interazioni con
gli altri componenti. In modo simile, una macchina dedicata che
esegue un applicazione specialistica di terze parti sar�� un buon cadidato.
</para>
<para>
In futuro, &SEL; �� orientato a tutti gli ambienti. Per questo,
la comunit�� e gli <abbrev>ISV</abbrev>s
(<firstterm>independent software vendors</firstterm>) dovranno
lavorare con gli sviluppatori &SEL; per produrre le policy necessarie. Finora,
�� stata scritta una <firstterm>strict policy</firstterm> molto restrittiva,
analogamente ad una <firstterm>targeted policy</firstterm> che mira
a specifici, demoni vulnerabili.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Che effetto ha &SEL; sulle applicazioni di terze parti?
</para>
</question>
<answer>
<para>
Uno degli scopi nell'implementare la policy targeted di &SEL; in &FC; ��
quello di permettere ad applicazioni di terze parti di funzionare senza modifiche. Questo
funziona perch�� la targeted policy �� trasparente a quelle
applicazioni che non prova a controllare e che ricadono
nella sicurezza di Linux standard. Queste applicazioni non saranno
eseguite in maniera extra sicura. Una policy deve essere scritta per
far si che queste applicazioni siano protette dal MAC.
</para>
<para>
Ci sono talmente tante variazioni nelle applicazioni di terze parti che ��
impossibile predire come si comporterebbero con &SEL;, anche
eseguendo la targeted policy. Le problematiche insorgenti possono talvolta essere
fissate nella policy. Puoi capitare che &SEL; ti mostri problemi
di sicurezza con la tua applicazione che non sapevi di avere, richiedendo
una modifica dell'applicazione per poter funzionare sotto &SEL;.
</para>
<para>
Un importante valore che i testers ed utenti di &FC; porteranno alla
comunit�� �� l'estensivo testing di applicazioni di terze parti. Tenendo
questo a mente, sei pregato di riportare le tue esperienze sull'appropriata
mailing list (<ulink
url="mailto:fedora-selinux-list@redhat.com">fedora-selinux-list(a)redhat.com</ulink>)
per discuterne.
</para>
</answer>
</qandaentry>
</qandadiv>
</qandaset>
</section>
</article>
18 years, 5 months
release-notes RELEASE-NOTES-master-it.xml,1.1,NONE
by fedora-docs-commits@redhat.com
Author: tombo
Update of /cvs/docs/release-notes
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21552/release-notes
Removed Files:
RELEASE-NOTES-master-it.xml
Log Message:
--- RELEASE-NOTES-master-it.xml DELETED ---
18 years, 5 months