From deny@monaco.net Fri Aug 24 17:07:34 2007 From: deny To: traduc@traduc.org Subject: [Traduc] dtd Date: Fri, 24 Aug 2007 17:07:10 +0200 Message-ID: <46CEF41E.3030108@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5963439023897199587==" --===============5963439023897199587== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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) voici la section en cause
Un <foreignphrase>Shell</foreignphrase> sécurisé Quand Tatu Ylonen à l'origine a écrit ssh, on l'a considéré comme un substitut de telnet et de rsh, qui sont des programmes/protocoles pour se connecter à distance (pour un accès distant à un shell). Cependant, ssh est un protocole réseau, ainsi il peut être utilisé pour créer des communications sécurisées entre des machines. Chaque serveur ssh posséde une clé privée——souvent située dans /etc/ssh/ssh_host_rsa_key. Souvent, il y a une seconde clé privée dans /etc/ssh/ssh_host_dsa_key. 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 .pub) et de les distribuer à toutes les machines du réseau. La manière la plus simple de faire ceci est de se rendre sur chaque ordinateur est de copier ces fichiers dans une clé USB (Universal Serial Bus, Bus série universel) : 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 L'administrateur crée alors un fichier known hosts : 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 Ce fichier known_hosts est ensuite copié dans /etc/ssh/ssh_known_hosts pour chaque machine. En conclusion, nous avons définit des paramètres de configuration echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config pour chaque machine. (Les utilisateurs de chaque ordinateur peuvent également devoir modifier le fichier de configuration $HOME/.ssh/config s'il existe et supprimer/editer $HOME/.ssh/known_hosts s'il existe). 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 ssh est plus complexe et il ne nous concerne pas ici). Ainsi, à présent, à partir d'Abdul on peut se connecter via ssh 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 /etc/ssh/sshd_config. Ce procédé pourrait être risqué pour Chin, à moins que l'utilisateur root sur Abdul soit considéré comme équivalent à l'utilisateur root de Chin. Que penser de types d'échange de données autres (que ssh) ? Heureusement, ceci aussi a été considéré. Si Abdul veut à présent ouvrir le port TCP (Transmission Control Protocol, protocole de contrôle de transmissions) (disons) 80 de Chin, alors Abdul éxecute ssh -q -f -N -L 8080:localhost:80 Chin À présent, se connecter à depuis Abdul donne accès au serveur web de Chin. Que pensez-vous de sécuriser toutes les données échangées ? Ceci a aussi été pris en compte. En fait, sous ssh il existe au moins deux manières : Les applications qui sont capables d'employer le protocole SOCKS (comme Mozilla et Thunderbird) peuvent utiliser un tunnel crée par cette commande : ssh -q -f -N -D 1080 Chin Il y a également des bibliothèques de wrapper comme tsocks qui peut apprendre à n'importe quelle application TCP comment utiliser SOCKS On peut également créer un tunnel TCP entre deux hôtes : ssh -q -f -N -w 0:any Chin En dépit de ses efforts, SSH ne convient pas toujours au problème que nous nous proposons de résoudre pour les raisons suivantes : Le mécanisme de distribution des clés est complexe. Ce n'est pas une bonne idée de percer un tunnel TCP au-dessus de TCP ainsi que l'explique Olaf Titz dans un article. Nous devons installer des tunnels entre chaque paire d'hôtes dans le réseau ; et c'est fastidieux.
-- merci pour toute aide --===============5963439023897199587==-- From deny@monaco.net Fri Aug 24 17:17:48 2007 From: deny To: traduc@traduc.org Subject: Re: [Traduc] dtd Date: Fri, 24 Aug 2007 17:17:26 +0200 Message-ID: <46CEF686.5090608@monaco.net> In-Reply-To: <46CEF41E.3030108@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7036194834285383946==" --===============7036194834285383946== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable deny a =C3=A9crit : > bonjour > je perd decidemment plus de temps =C3=A0 debugger selon docbook qu'=C3=A0 t= raduire > voici par exemple une erreur tellement pr=C3=A9cise qu'elle oblige =C3=A0 v= erifier=20 > 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 =C3=A0 toute allure ! erreur sur le message xmllint --valid --noout lg141c.xml lg141c.xml:174: element section: validity error : Element section=20 content does not follow the DTD, expecting (sectioninfo? , (title ,=20 subtitle? , titleabbrev?) , (toc | lot | index | glossary |=20 bibliography)* , (((calloutlist | glosslist | bibliolist | itemizedlist=20 | orderedlist | segmentedlist | simplelist | variablelist | caution |=20 important | note | tip | warning | literallayout | programlisting |=20 programlistingco | screen | screenco | screenshot | synopsis |=20 cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis |=20 constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara |=20 para | simpara | address | blockquote | graphic | graphicco |=20 mediaobject | mediaobjectco | informalequation | informalexample |=20 informalfigure | informaltable | equation | example | figure | table |=20 msgset | procedure | sidebar | qandaset | task | anchor | bridgehead |=20 remark | highlights | abstract | authorblurb | epigraph | indexterm |=20 beginpage)+ , (refentry* | section* | simplesect*)) | refentry+ |=20 section+ | simplesect+) , (toc | lot | index | glossary |=20 bibliography)*), got (title para para para command para programlisting=20 para command para para para para command para para orderedlist para=20 orderedlist ) >=20 > voici la section en cause >=20 >=20 >
Un <foreignphrase>Shell</foreignphrase>=20 > s=C3=A9curis=C3=A9 > > Quand Tatu Ylonen =C3=A0 l'origine a =C3=A9crit=20 > ssh, on l'a consid=C3=A9r=C3= =A9=20 > comme un substitut de telnet et de=20 > rsh, qui sont des=20 > programmes/protocoles pour se connecter =C3=A0 distance (pour un acc=C3=A8s= =20 > distant =C3=A0 un shell). Cependant,=20 > ssh est un protocole=20 > r=C3=A9seau, ainsi il peut =C3=AAtre utilis=C3=A9 pour cr=C3=A9er des commu= nications=20 > s=C3=A9curis=C3=A9es entre des machines. > > > Chaque serveur ssh poss=C3=A9= de=20 > une cl=C3=A9 priv=C3=A9e—=E2=80=94souvent situ=C3=A9e dans class=3D"directory">/etc/ssh/ssh_host_rsa_key. Souvent, il y a=20 > une seconde cl=C3=A9 priv=C3=A9e dans class=3D"directory">/etc/ssh/ssh_host_dsa_key. Le travail d'un=20 > administrateur r=C3=A9seau est de rassembler les cl=C3=A9s publiques associ= =C3=A9es =C3=A0=20 > chacune de ces cl=C3=A9s priv=C3=A9es (au m=C3=AAme endroit, avec une exten= sion=20 > .pub) et de les distribuer =C3=A0 toutes les machines = > du r=C3=A9seau.=09 > > > La mani=C3=A8re la plus simple de faire ceci est de se rendre sur chaque=20 > ordinateur est de copier ces fichiers dans une cl=C3=A9=20 > USB=20 > (Universal Serial Bus, Bus s=C3=A9rie=20 > universel) : > > >=20 > 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 > > > L'administrateur cr=C3=A9e alors un fichier known=20 > hosts : > > > for type in rsa dsa > do > for i in /media/usb/*.$type.pub > do > addr=3D$(basename $i .$type.pub) > (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts > done > done > > > Ce fichier known_hosts est ensuite copi=C3=A9 dans=20 > /etc/ssh/ssh_known_hosts pour=20 > chaque machine. En conclusion, nous avons d=C3=A9finit des param=C3=A8tres = de=20 > configuration > > > echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config > > > pour chaque machine. (Les utilisateurs de chaque ordinateur peuvent=20 > =C3=A9galement devoir modifier le fichier de configuration class=3D"directory">$HOME/.ssh/config s'il existe et=20 > supprimer/editer class=3D"directory">$HOME/.ssh/known_hosts s'il existe).=09 > =09 > > Apr=C3=A8s cette proc=C3=A9dure (=C3=A9videmment) prolixe (mais pas diffici= le), Abdul=20 > et Chin poss=C3=A9dent les cl=C3=A9s publiques de chacun. Ainsi, Abdul peut= =20 > chiffrer des paquets que seul Chin peut lire et Chin peut v=C3=A9rifier des= =20 > signatures faites par Abdul. (Le v=C3=A9ritable protocole=20 > ssh est plus complexe et=20 > il ne nous concerne pas ici). > > > Ainsi, =C3=A0 pr=C3=A9sent, =C3=A0 partir d'Abdul on peut se connecter via = > ssh sur Chin et =C3=AAtre s= =C3=BBr=20 > que c'est Chin qui r=C3=A9pond. Chin demandera cependant le mot de passe = =C3=A0=20 > moins que tous les serveurs permettent la directive=20 > HostBasedAuthentication dans class=3D"directory">/etc/ssh/sshd_config. Ce proc=C3=A9d=C3=A9 p= ourrait=20 > =C3=AAtre risqu=C3=A9 pour Chin, =C3=A0 moins que l'utilisateur=20 > root sur Abdul soit consid=C3=A9r=C3=A9 comm= e=20 > =C3=A9quivalent =C3=A0 l'utilisateur root de= Chin. > > > Que penser de types d'=C3=A9change de donn=C3=A9es autres (que=20 > ssh) ? Heureusement,=20 > ceci aussi a =C3=A9t=C3=A9 consid=C3=A9r=C3=A9. Si Abdul veut =C3=A0 pr=C3= =A9sent ouvrir le port=20 > TCP (Transmission Control=20 > Protocol, protocole de contr=C3=B4le de transmissions)=20 > (disons) 80 de Chin, alors Abdul =C3=A9xecute > > > ssh -q -f -N -L 8080:localhost:80 Chin > > > =C3=80 pr=C3=A9sent, se connecter =C3=A0 =20 > depuis Abdul donne acc=C3=A8s au serveur web= =20 > de Chin. > > > Que pensez-vous de s=C3=A9curiser toutes les donn=C3=A9es =C3=A9chang=C3=A9= es ? Ceci a=20 > aussi =C3=A9t=C3=A9 pris en compte. En fait, sous=20 > ssh il existe au moins=20 > deux mani=C3=A8res : > > > > Les applications qui sont capables d'employer le protocole=20 > SOCKS (comme Mozilla et=20 > Thunderbird) peuvent utiliser un tunnel cr=C3=A9= e=20 > par cette commande : > =09 > ssh -q -f -N -D 1080 Chin > > Il y a =C3=A9galement des biblioth=C3=A8ques de=20 > wrapper comme=20 > tsocks qui peut apprendre =C3=A0 = > n'importe quelle application TCP comment utiliser=20 > SOCKS > On peut =C3=A9galement cr=C3=A9er un tunnel TCP entr= e deux=20 > h=C3=B4tes : > > ssh -q -f -N -w 0:any Chin > > > > En d=C3=A9pit de ses efforts,=20 > SSH ne convient pas=20 > toujours au probl=C3=A8me que nous nous proposons de r=C3=A9soudre pour les= =20 > raisons suivantes : > > > > Le m=C3=A9canisme de distribution des cl=C3=A9s est=20 > complexe. > Ce n'est pas une bonne id=C3=A9e de percer un tunnel=20 > TCP au-dessus de TCP ainsi que=20 > l'explique url=3D"http://sites.inka.de/sites/bigred/devel/tcp-tcp.html">Olaf Titz=20 > dans un article. > Nous devons installer des tunnels entre chaque paire d'h=C3=B4tes dans= =20 > le r=C3=A9seau ; et c'est fastidieux. > >
--=20 -----------------------------------------------------------------------------= -----------------------------------------------------------------------------= ------ Moi j'aimerais entrer =C3=A0 la NASA pour pouvoir mettre des miettes de BN=20 entre les touches de leur claviers. C'est une technique de hack tr=C3=A8s=20 fourbe parce qu'apr=C3=A8s ils croient appuyer sur une touche, mais ils=20 appuient sur plusieurs. --===============7036194834285383946==-- From deny@monaco.net Fri Aug 24 18:10:25 2007 From: deny To: traduc@traduc.org Subject: Re: [Traduc] dtd Date: Fri, 24 Aug 2007 18:10:05 +0200 Message-ID: <46CF02DD.9090008@monaco.net> In-Reply-To: <46CEF686.5090608@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8767295073148466601==" --===============8767295073148466601== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit deny a écrit : > deny a écrit : >> 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 ! > > erreur sur le message > > trouvé l'erreur un au lieu de ou docbook renaclait mais l'erreur n'etait pas explicite . --===============8767295073148466601==--