bonjour je perd decidemment plus de temps à debugger selon docbook qu'à traduire voici par exemple une erreur tellement précise qu'elle oblige à verifier tout le passage section a la recherche de l'erreur invalidante : je pense franchement qu'il serait bon de trouver un format de traduction moins contraignant , sinon beaucoup vont partir à toute allure !
lg141c.xml:169: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | bibliolist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | task | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+, got (para command para) </para></listitem></orderedlist>
voici la section en cause
<section id="shell"><title>Un <foreignphrase>Shell</foreignphrase> sécurisé</title> <para> Quand Tatu Ylonen à l'origine a écrit <application><acronym>ssh</acronym></application>, on l'a considéré comme un substitut de <application>telnet</application> et de <application><acronym>rsh</acronym></application>, qui sont des programmes/protocoles pour se connecter à distance (pour un accès distant à un <foreignphrase>shell</foreignphrase>). Cependant, <application><acronym>ssh</acronym></application> est un protocole réseau, ainsi il peut être utilisé pour créer des communications sécurisées entre des machines. </para> <para> Chaque serveur <application><acronym>ssh</acronym></application> posséde une clé privée——souvent située dans <filename class="directory">/etc/ssh/ssh_host_rsa_key</filename>. Souvent, il y a une seconde clé privée dans <filename class="directory">/etc/ssh/ssh_host_dsa_key</filename>. Le travail d'un administrateur réseau est de rassembler les clés publiques associées à chacune de ces clés privées (au même endroit, avec une extension <filename>.pub</filename>) et de les distribuer à toutes les machines du réseau. </para> <para> La manière la plus simple de faire ceci est de se rendre sur chaque ordinateur est de copier ces fichiers dans une clé <application><acronym>USB</acronym></application> (<foreignphrase>Universal Serial Bus</foreignphrase>, Bus série universel) : </para> <command>
cp /etc/ssh/ssh_host_rsa_key.pub /media/usb/<ip_addr>.rsa.pub cp /etc/ssh/ssh_host_dsa_key.pub /media/usb/<ip_addr>.dsa.pub </command> <para> L'administrateur crée alors un fichier <filename>known hosts</filename> : </para> <programlisting> for type in rsa dsa do for i in /media/usb/*.$type.pub do addr=$(basename $i .$type.pub) (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts done done </programlisting> <para> Ce fichier <filename>known_hosts</filename> est ensuite copié dans <filename class="directory">/etc/ssh/ssh_known_hosts</filename> pour chaque machine. En conclusion, nous avons définit des paramètres de configuration </para> <command> echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config </command> <para> pour chaque machine. (Les utilisateurs de chaque ordinateur peuvent également devoir modifier le fichier de configuration <filename class="directory">$HOME/.ssh/config</filename> s'il existe et supprimer/editer <filename class="directory">$HOME/.ssh/known_hosts</filename> s'il existe). </para> <para> Après cette procédure (évidemment) prolixe (mais pas difficile), Abdul et Chin possédent les clés publiques de chacun. Ainsi, Abdul peut chiffrer des paquets que seul Chin peut lire et Chin peut vérifier des signatures faites par Abdul. (Le véritable protocole <application><acronym>ssh</acronym></application> est plus complexe et il ne nous concerne pas ici). </para> <para> Ainsi, à présent, à partir d'Abdul on peut se connecter via <application><acronym>ssh</acronym></application> sur Chin et être sûr que c'est Chin qui répond. Chin demandera cependant le mot de passe à moins que tous les serveurs permettent la directive HostBasedAuthentication dans <filename class="directory">/etc/ssh/sshd_config</filename>. Ce procédé pourrait être risqué pour Chin, à moins que l'utilisateur <foreignphrase>root</foreignphrase> sur Abdul soit considéré comme équivalent à l'utilisateur <foreignphrase>root</foreignphrase> de Chin. </para> <para> Que penser de types d'échange de données autres (que <application><acronym>ssh</acronym></application>) ? Heureusement, ceci aussi a été considéré. Si Abdul veut à présent ouvrir le port <acronym>TCP</acronym> (<foreignphrase>Transmission Control Protocol</foreignphrase>, protocole de contrôle de transmissions) (disons) 80 de Chin, alors Abdul éxecute </para> <command> ssh -q -f -N -L 8080:localhost:80 Chin </command> <para> À présent, se connecter à <ulink url="http://localhost:8080"></ulink> depuis Abdul donne accès au serveur <foreignphrase>web</foreignphrase> de Chin. </para> <para> Que pensez-vous de sécuriser toutes les données échangées ? Ceci a aussi été pris en compte. En fait, sous <application><acronym>ssh</acronym></application> il existe au moins deux manières : </para> <orderedlist numeration="arabic"> <listitem><para> Les applications qui sont capables d'employer le protocole <abbrev>SOCKS</abbrev> (comme <application>Mozilla</application> et <application>Thunderbird</application>) peuvent utiliser un tunnel crée par cette commande : <command> ssh -q -f -N -D 1080 Chin </command> Il y a également des bibliothèques de <foreignphrase>wrapper</foreignphrase> comme <application>tsocks</application> qui peut <quote>apprendre</quote> à n'importe quelle application <acronym>TCP</acronym> comment utiliser <abbrev>SOCKS</abbrev></para></listitem><listitem><para> On peut également créer un tunnel <acronym>TCP</acronym> entre deux hôtes : <command> ssh -q -f -N -w 0:any Chin </command> </para></listitem></orderedlist> <para> En dépit de ses efforts, <application><acronym>SSH</acronym></application> ne convient pas toujours au problème que nous nous proposons de résoudre pour les raisons suivantes : </para> <orderedlist numeration="arabic"> <listitem><para> Le mécanisme de distribution des clés est complexe.</para></listitem><listitem><para> Ce n'est pas une bonne idée de percer un tunnel <acronym>TCP</acronym> au-dessus de <acronym>TCP</acronym> ainsi que l'explique <ulink url="http://sites.inka.de/sites/bigred/devel/tcp-tcp.html">Olaf Titz dans un article.</ulink></para></listitem><listitem><para> Nous devons installer des tunnels entre chaque paire d'hôtes dans le réseau ; et c'est fastidieux. </para></listitem></orderedlist> </section>