Ga= zette=20 Linux/Brouillons/lg149-C VPN=20 Networking

Ga= zette=20 Linux/Brouillons/lg149-C VPN=20 Networking192009-0= 3-02=20 18:51:33KamalSawalToure182009-03-02=20 10:53:00KamalSawalToureRel= ecture=20 faite. Traduction finie. Merci pour votre=20 patience172009-= 03-02=20 01:08:45KamalSawalToure162009-03-02=20 01:07:57KamalSawalTourej'a= i=20 fini. Il reste la=20 relecture152009= -02-23=20 15:28:50KamalSawalToure142009-02-23=20 13:35:28KamalSawalToure132009-02-23=20 11:26:29KamalSawalToure122009-02-10=20 18:51:54KamalSawalToure112009-02-10=20 14:57:25KamalSawalToure102009-02-10=20 13:33:23KamalSawalToure92009-02-10=20 12:41:40KamalSawalToure82008-12-07=20 08:27:06KamalSawalToure72008-10-17=20 17:02:24KamalSawalToure62008-10-17=20 17:00:13KamalSawalToure52008-10-17=20 16:28:34KamalSawalToure42008-10-14=20 12:58:08KamalSawalToure32008-10-14=20 11:47:13KamalSawalToure22008-10-01=20 08:50:27KamalSawalToure12008-09-30=20 15:51:29KamalSawalToure

Configuration=20 d'un R=C3=A9seau Priv=C3=A9 Virtuel (VPN)Cr=C3=A9er son propre = R=C3=A9seau=20 Virtuel Priv=C3=A9 (VPN) est assez facile sur des plateformes qui sont=20 livr=C3=A9es avec un pilote tun: cela permet de traiter le flux des paquets=20 r=C3=A9seaux au niveau de l'espace utilisateur. Bien que cela soit=20 consid=C3=A9rablement plus facile que de faire de la programmation r=C3=A9sea= u=20 dans le noyau, il reste cependant quelques d=C3=A9tails =C3=A0 prendre en com= pte.=20 Cet article vous guidera =C3=A0 travers mes trouvailles.=20 IFF_TUN Versus IFF_TAP=20 Le Pilote tun est un p=C3=A9riph=C3=A9rique deux-en-un:=20 Un P=C3=A9riph=C3=A9rique point =C3=A0 p= oint=20 (IFF_TUN). Le p=C3=A9riph=C3=A9rique TUN permet le traitement de paquets IP. = Un p=C3=A9riph=C3=A9rique Ethernet (IFF_TAP= ). Le=20 p=C3=A9riph=C3=A9rique TAP traite les trames Ethernet.=20 Cet article parle du code =C3=A0=20 =C3=A9crire pour le p=C3=A9riph=C3=A9rique Ethernet.Si vous choisissez le p= =C3=A9riph=C3=A9rique=20 IP, alors vous g=C3=A9n=C3=A8rerez 18 octets par paquet trait=C3=A9; le trafi= c est=20 certes moins important (l'en-t=C3=AAte et la queue du paquet Ethernet), mais = vous aurez =C3=A0 coder un peu plus pour mettre en place votre r=C3=A9seau.=20 Activation du pilote=20 Premi=C3=A8rement, on doit s'assurer que le pilote tun est=20 actif.Sur mon syst=C3=A8me Debian, je dois tout simplement le charger:=20 # /sbin/modprobe tun # /sbin/lsmod | grep tun tun=20 10208 0 # /bin/ls -l /dev/net/tun crw-rw-rw- 1=20 root root 10, 200 2008-02-10 11:30 /dev/net/tun La Configuration Pour des besoins=20 de d=C3=A9monstration, on mettra en place un r=C3=A9seau virtuel de deux h=C3= =B4tes.=20 Une fois qu'on a mis la main sur les paquets Ethernet, nous utiliserons=20 l'encapsulation UDP pour les faire transiter d'une interface virtuelle=20 sur l'h=C3=B4te A vers une interface virtuelle sur l'h=C3=B4te B et vice-vers= a. Le=20 socket UDP sera utilis=C3=A9 en mode non-connect=C3=A9; cela a l'avantage de = nous=20 permettre d'utiliser le m=C3=AAme socket pour envoyer et recevoir des paquets= =20 depuis n'importe quel autre h=C3=B4te de notre r=C3=A9seau virtuel. Toutefois= , la=20 nature non-connect=C3=A9e de notre socket UDP, complique la r=C3=A9ception du= =20 chemin MTU (plus de d=C3=A9tails dessus dans les prochaines lignes).=20 Chaque h=C3=B4te de notre r=C3=A9seau virtuel ex=C3=A9cutera une= instance=20 du programme de d=C3=A9monstration. Pour l'illustrer, le trafic d'une=20 application (telnet dans le cas pr=C3=A9sent) sur l'h=C3=B4te A vers l'applic= ation=20 correspondante (inetd/telnetd) vers l'h=C3=B4te B, utilisera le chemin=20 suivant: Le m=C3=A9canisme de=20 d=C3=A9couverte En pratique, nous avons besoin d'un=20 m=C3=A9canisme pour faire correspondre les adresses IP virtuelles aux=20 adresses IP r=C3=A9elles. Il nous appartient de bidouiller une m=C3=A9thode d= e=20 d=C3=A9couverte pour r=C3=A9soudre ce probl=C3=A8me de correspondance; cepend= ant comme=20 cela n'est pas en rapport direct avec notre sujet du jour, ni n=C3=A9cessaire= =20 pour les besoins de notre petite d=C3=A9monstration d=C3=A9crite ici, nous al= lons=20 tricher et laisser le programme de tunnelling =C3=A9tablir les=20 correspondances par des lignes de commande:=20 Host A# ./udptun=20 Usage: ./udptun local-tun-ip remote-physical-ip Host A# ./udptun=20 172.16.0.1 192.168.2.103 Host B# ./udptun 172.16.0.111 192.168.2.113=20 Mise en=20 place de l'interface La premi=C3=A8re chose =C3=A0 fa= ire=20 est de cr=C3=A9er l'interface Ethernet virtuelle (tap). Cela se fait avec un = simple appel =C3=A0 la fonction open(): Ici, l'indicateur IFF_NO_PI requiert qu'on=20 manipule de trames brutes. Si on ne fait pas cela, les trames se verront=20 ajouter un en-t=C3=AAte de 4 octets. Interface setup: the IP address=20 L'interface virtuelle doit =C3=AAtre identifi=C3=A9e par une adr= esse=20 IP. On la d=C3=A9finira avec un appel de la fonction ioctl():=20 ifr_addr, &addr, sizeof(struct sockaddr)); if (ioctl(sock, SIOCSIFADDR, ifr_tun) < 0) { /*Erreur de traitement, retour*/ } /*Sera Utilis=C3=A9 plus tard pour d=C3=A9finir le MTU.*/ return sock; }]]>Le PMTU (Path Maximum=20 Transmission Unit) La seul =C3=A9l=C3=A9ment que nous= =20 avons =C3=A0 configurer est le MTU (Maximum Transmit Unit) de l'interface.=20 Pour notre interface pseudo-Ethernet, le MTU est la charge la plus=20 importante que les trames Ethernet peuvent transporter. On d=C3=A9finira le=20 PMTU en fonction du MTU. Pour faire simple, on dira que le=20 PMTU est le paquet le plus large qui peut traverser le chemin allant=20 d'un h=C3=B4te =C3=A0 sa destination sans subir de fragmentation. Le=20 PMTU est un param=C3=A8tre important =C3=A0 prendre en compte pour que tout s= e=20 passe bien. Consid=C3=A9rez ceci: en (r=C3=A9)injectant vos trames dans le no= yau,=20 elles se verront attribuer des en-t=C3=AAtes (IP, UDP et Ethernet)=20 suppl=C3=A9mentaires. Si la taille de la trame que vous avez envoy=C3=A9e au = noyau=20 est trop proche du PMTU, la trame finale qui sera envoy=C3=A9e =C3=A0 partir = de=20 l'interface r=C3=A9elle pourrait =C3=AAtre plus grande que le PMTU. Au pire d= es=20 cas, une telle trame sera perdue quelque part en route. Au meilleur des=20 cas, la trame sera fragment=C3=A9e en deux et la premi=C3=A8re partie sera tr= ait=C3=A9e=20 =C3=A0 100%, ce qui ne sera pas le cas pour la seconde partie.=20 Pour =C3=A9viter cela, on doit d=C3=A9couvrir la valeur du PMTU = et=20 s'assurer que la nouvelle trame Ethernet sera correctement dimensionn=C3=A9e = pour le PMTU. Ensuite, on soustraira du PMTU la taille des nouvelles=20 en-t=C3=AAtes et on donnera cette valeur au MTU de l'interface virtuelle.=20 La t=C3=A2che est facile sous Linux, pour un socket TCP: on doit= =20 juste s'assurer que les m=C3=A9canismes de d=C3=A9couverte du PMTU par le noy= au=20 sont configur=C3=A9s, et c'est tout. Par contre pour les sockets= =20 UDP, nous les utilisateurs, avons la responsabilit=C3=A9 de nous assurer que = les datagrammes UDP sont de taille correcte. Si le socket UDP est=20 connect=C3=A9 =C3=A0 l'h=C3=B4te correspondant, un simple appel appel de la f= onction=20 getsockopt()avec l'indicateur IP_MTU positionn=C3=A9, nous donnera le PMTU=20 En ce qui concerne les sockets non-connect=C3=A9s, on doit=20 analyser le PMTU. Premi=C3=A8rement, le socket doit =C3=AAtre configur=C3=A9 = de fa=C3=A7on =C3=A0=20 ce que les datagrammes ne soient pas fragment=C3=A9s (positionner=20 l'indicateur DF); ensuite, on doit configurer de fa=C3=A7on =C3=A0 =C3=AAtre = averti des=20 erreurs ICMP que cela pourrait g=C3=A9n=C3=A9rer. Si un h=C3=B4te ne peut pas= g=C3=A9rer la=20 taille du datagramme sans le fragmenter, alors il devra nous en informer=20 (enfin, on l'esp=C3=A8re): Ensuite, on envoie des datagrammes analys=C3=A9s de = diverses tailles: Pour=20 finir, on farfouille parmi les erreurs jusqu'=C3=A0 trouver le bon PMTU. Si=20 on a une erreur de PMTU, on ajuste la taille du datagramme et on=20 recommence =C3=A0 envoyer les datagrammes jusqu'=C3=A0 ce que la destination = soit=20 atteinte: 0) { /* R=C3=A9ponse re=C3=A7ue. Fin de la d=C3=A9couverte du PMTU. Retou= r.*/ } msg.msg_name =3D (unsigned char*)&addr; msg.msg_namelen =3D sizeof(addr); msg.msg_iov =3D &iov; msg.msg_iovlen =3D 1; msg.msg_flags =3D 0; msg.msg_control =3D cbuf; msg.msg_controllen =3D sizeof(cbuf); res =3D recvmsg(sock, &msg, MSG_ERRQUEUE); if (res < 0) { if (errno !=3D EAGAIN) perror("recvmsg"); /*Nothing for now, return.*/ } for (cmsg =3D CMSG_FIRSTHDR(&msg); cmsg; cmsg =3D CMSG_NXTHDR(&msg,=20 cmsg)) { if (cmsg->cmsg_level =3D=3D SOL_IP) { if (cmsg->cmsg_type =3D=3D IP_RECVERR) { err =3D (struct sock_extended_err *) CMSG_DATA(cmsg); } } } if (err =3D=3D NULL) { /*D=C3=A9couvrte du PMTU: pas d'info jusque l=C3=A0. Retour, mais=20 continue =C3=A0 analyser.*/ } mtu =3D 0; switch (err->ee_errno) { ... case EMSGSIZE: debug(" EMSGSIZE pmtu %d\n", err->ee_info); mtu =3D err->ee_info; break; ... } /*end switch*/ return mtu; /*Mais continue =C3=A0 analyser jusqu'=C3=A0 ce que l'h=C3= =B4te=20 distant soit atteint!*/]]>Une derni=C3=A8re chose: le PMTU est= =20 tenu de changer dans le temps. On devra donc le tester de temps en temps=20 et ensuite configurer le MTU de l'interface virtuelle en fonction des=20 r=C3=A9sultats du test. Si on veut =C3=A9viter toute cette gymnastique, on pe= ut=20 configurer le MTU de fa=C3=A7on s=C3=A9curis=C3=A9e mais moins optimale : cho= isir la=20 valeur la plus petit entre 576 et le MTU de l'interface physique (moins=20 l'en-t=C3=AAte que nous avons mentionn=C3=A9, bien entendu.)=20 Configuration de l'interface: le=20 MTU Apr=C3=A8s avoir finalement obtenu cette valeur=20 magique qu'est le PMTU, nous pouvons correctement configurer le MTU de=20 notre interface: ifr_mtu =3D mtu; if (ioctl(sock, SIOCSIFMTU, ifr_tun) < 0) { /*Erreur de Traitement*/ }]]>Encapsulation=20 UDP Nous avons maintenant une interface=20 virtuelle bien configur=C3=A9e et qui fonctionne. Tout ce que nous avons =C3= =A0=20 faire est de relayer les trames dans les deux directions. Premi=C3=A8rement, = il faut ouvrir un socket UDP non-connect=C3=A9 (Je vous =C3=A9pargne les d=C3= =A9tails),=20 et ensuite: Lire=20 les paquets du fichier descriptif du tap et les envoyer =C3=A0 l'adresse IP=20 physique distante de notre h=C3=B4te correspondant; ceci enverra les paquets = dans une seule direction.=20 0) sendto(_udp_fd, buf, recvlen, 0, (struct=20 sockaddr*)&cliaddr, clilen); ]]>Avertissement:=20 La lecture du fichier descriptif du tap va provoquer un blocage. Cela=20 veut dire que la fonction read() ne va pas =C3=AAtre interrompue m=C3=AAme si= on=20 ferme le descripteur sous-jacent du fichier. On est donc oblig=C3=A9=20 d'utiliser les fonctions poll()/select() sur ce descripteur de fichier=20 avant d'executer la fonction read() dessus si on veut pouvoir terminer=20 ce thread proprement.=20 lire les=20 datagrammes du socket UDP et les envoyer =C3=A0 travers le descripteur de=20 fichier tap : les donn=C3=A9es circuleront maintenant dans la direction=20 oppos=C3=A9e. 0) write(_tun_fd, buf, recvlen); ]]>Notez=20 qu'en pratique, si on a plus de deux h=C3=B4tes dans son r=C3=A9seau virtuel,= on=20 doit regarder le contenu des trames pour v=C3=A9rifier les adresses IP source= =20 et destination avant de d=C3=A9cider o=C3=B9 envoyer la trame. = On=20 peut t=C3=A9l=C3=A9charger les sources des fichiers udptun.c, ttools.c, ttool= s.h=20 et pathmtu.c avec le Makefile; tout ce dont on parl=C3=A9 ci-dessus est aussi= =20 t=C3=A9l=C3=A9chargeable sous la forme d'une archive tar. P comme Priv=C3=A9 Comme on a le=20 contr=C3=B4le total du trafic de notre r=C3=A9seau virtuel, on peut le crypte= r=20 dans l'espace utilisateur. Pour les besoins de cette d=C3=A9monstration, nous= =20 allons construire un VPN complet, que nous allons crypter avec IPSEC=20 (remarque: IPSEC a aussi une fonctionnalit=C3=A9 int=C3=A9gr=C3=A9e de tunnel= ling).=20 Sous Debian, il faut juste installer le paquetage=20 ipsec-tools et utiliser ces fichiers pour des manipulations manuelles:=20 Pour l'h=C3=B4te A: ## Vider le SAD et SPD flush; spdflush;=20 # A & B add 172.16.0.1 172.16.0.111 ah 15700 -A=20 hmac-md5 "123456789.123456"; add 172.16.0.111 172.16.0.1 ah 24500=20 -A hmac-md5 "123456789.123456"; add 172.16.0.1 172.16.0.111 esp=20 15701 -E 3des-cbc "123456789.123456789.1234"; add 172.16.0.111=20 172.16.0.1 esp 24501 -E 3des-cbc "123456789.123456789.1234"; # A=20 spdadd 172.16.0.1 172.16.0.111 any -P out ipsec=20 esp/transport//require ah/transport//require;=20 spdadd 172.16.0.111 172.16.0.1=20 any -P in ipsec esp/transport//require ah/transport//require;=20 Pour=20 l'h=C3=B4te B: ## Vide= r=20 le SAD et SPD flush; spdflush; # A & B add 172.16.0.1=20 172.16.0.111 ah 15700 -A hmac-md5 "123456789.123456"; add=20 172.16.0.111 172.16.0.1 ah 24500 -A hmac-md5 "123456789.123456";=20 add 172.16.0.1 172.16.0.111 esp 15701 -E 3des-cbc=20 "123456789.123456789.1234";=20 add 172.16.0.111 172.16.0.1=20 esp 24501 -E 3des-cbc "123456789.123456789.1234";=20 #dump ah; #dump esp; # B spdadd=20 172.16.0.111 172.16.0.1 any -P out ipsec esp/transport//require ah/transport//require;=20 spdadd 172.16.0.1 172.16.0.111=20 any -P in ipsec esp/transport//require ah/transport//require;=20 Remarquez=20 comme le m=C3=A9canisme de cryptage tout entier est li=C3=A9 aux adresses=20 virtuelles et comme il vous isole des r=C3=A9seaux physiques sur lesquels vos= =20 h=C3=B4tes se trouvent. Vous pouvez directement t=C3=A9l=C3=A9charger le fich= ier=20 ipsec-tools.conf. Le VPN en=20 marche C'est parti! Faisons un ping de 100=20 octets sur l'interface virtuelle de l'autre h=C3=B4te:=20 Host A$ ping -s 100=20 172.16.0.111 Regardons le trafic=20 avec tcpdump sur l'interface virtuelle:: #tcpdump -i tap0 .. 15:43:27.739218 IP 172.16.0.1 >=20 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1d):=20 ESP(spi=3D0x00003d55,seq=3D0x1d), length 128=20 15:43:27.740673 IP 172.16.0.111 >=20 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1d): ESP(spi=3D0x00005fb5,seq=3D0x1d), length 128=20 15:43:28.738741 IP 172.16.0.1 >=20 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1e):=20 ESP(spi=3D0x00003d55,seq=3D0x1e), length 128=20 15:43:28.740170 IP 172.16.0.111 >=20 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1e): ESP(spi=3D0x00005fb5,seq=3D0x1e), length 128=20 15:43:39.494298 IP 172.16.0.1 >=20 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1f):=20 ESP(spi=3D0x00003d55,seq=3D0x1f), length 64=20 15:43:39.496818 IP 172.16.0.111 >=20 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1f): ESP(spi=3D0x00005fb5,seq=3D0x1f), length 40=20 Sur=20 l'interface physique: # tcpdump -i eth2 .. 15:45:46.878156 IP=20 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 length 186=20 15:45:46.879021 IP=20 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 length 186=20 15:45:47.879479 IP=20 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 length 186=20 15:45:47.887054 IP=20 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 length 186=20 15:45:48.880268 IP=20 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 length 186=20 15:45:48.882738 IP=20 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 length 186=20 Tous=20 les chiffres en gras sont des charges utiles. Quand il sort de=20 l'interface virtuelle, le datagramme crypt=C3=A9 est de 186 octets: 14 octets= =20 pour l'en-t=C3=AAte Ethernet, 20 pour l'en-t=C3=AAte IP, un en-t=C3=AAte AH d= e 24=20 octets et un ESP pour les 128 octets restants. Quand il=20 sort de l'interface physique, le datagramme est de 232 octets: 14 octets=20 pour l'en-t=C3=AAte Ethernet, 20 octets pour l'en-t=C3=AAte IP, 8 pour l'en-t= =C3=AAte=20 UDP, 186 octets de charge physique et 4 octets pour le bloc de fin de la=20 trame Ethernet. Nous avons donc rajout=C3=A9 46 octets par datagramme.=20 Ressources=20 Th= e=20 TUN/TAP kernel documentation=20 The Path MTU Discovery=20 RFC The Linux IPv4 man page=20 The RFC=20 Sourcebook

To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 11:52:34 +0100 Message-ID: <49AD0BF2.60206@monaco.net> In-Reply-To: <49AD09B4.2000507@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6246833100734054150==" --===============6246833100734054150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> un wiki, on peut y =C3=A9crire, non? >=20 oui , on va m=C3=AAme dire que c'est un peu fait pour cela >> Apriori, le docbook cr=C3=A9=C3=A9 par MoinMoin passe bien les scripts (ce= ux du >> LDP, en tout cas pour l'instant) Il passe bien les scripts mais il g=C3=A9n=C3=A9re du code degueulasse, qu'il= va me falloir deux heures pour d=C3=A9boguer -rajouter les en-t=C3=AAtes -rajouter les tags docbook omis -faire une mise en page clarifi=C3=A9e voici d'ailleurs le code g=C3=A9n=C3=A9r=C3=A9 pour que chacun (mais il y a p= as vraiment pas grand monde, donc ca devrait =C3=AAtre rapide) puisse se faire une id=C3=A9e du travail =C3=A0 effectuer je vais sur le wiki je trouve la page envoy=C3=A9 par le traducteur je fais afficher en docbook et ensuite je r=C3=A9cup=C3=A8re le fichier g= =C3=A9n=C3=A9r=C3=A9 et attention les yeux,le voici le voila (et j'envoie ci-joint un exemple de fichier "propre", que je dois tirer de ce torchon ) Il n'y a pas un probl=C3=A8me, la ? > "-//OASIS//DTD DocBook XML V4.4//EN"=20 > "http://www.docbook.org/xml/4.4/docbookx.dtd">

= Gazette=20 > Linux/Brouillons/lg149-C VPN=20 > Networking192009= -03-02=20 > 18:51:33KamalSawalToure<= revision>182009-03-02=20 > 10:53:00KamalSawalToureR= electure=20 > faite. Traduction finie. Merci pour votre=20 > patience17200= 9-03-02=20 > 01:08:45KamalSawalToure<= revision>162009-03-02=20 > 01:07:57KamalSawalTourej= 'ai=20 > fini. Il reste la=20 > relecture1520= 09-02-23=20 > 15:28:50KamalSawalToure<= revision>142009-02-23=20 > 13:35:28KamalSawalToure<= revision>132009-02-23=20 > 11:26:29KamalSawalToure<= revision>122009-02-10=20 > 18:51:54KamalSawalToure<= revision>112009-02-10=20 > 14:57:25KamalSawalToure<= revision>102009-02-10=20 > 13:33:23KamalSawalToure<= revision>92009-02-10=20 > 12:41:40KamalSawalToure<= revision>82008-12-07=20 > 08:27:06KamalSawalToure<= revision>72008-10-17=20 > 17:02:24KamalSawalToure<= revision>62008-10-17=20 > 17:00:13KamalSawalToure<= revision>52008-10-17=20 > 16:28:34KamalSawalToure<= revision>42008-10-14=20 > 12:58:08KamalSawalToure<= revision>32008-10-14=20 > 11:47:13KamalSawalToure<= revision>22008-10-01=20 > 08:50:27KamalSawalToure<= revision>12008-09-30=20 > 15:51:29KamalSawalToure<= /revhistory>

Configuration=20 > d'un R=C3=A9seau Priv=C3=A9 Virtuel (VPN)Cr=C3=A9er son propr= e R=C3=A9seau=20 > Virtuel Priv=C3=A9 (VPN) est assez facile sur des plateformes qui sont=20 > livr=C3=A9es avec un pilote tun: cela permet de traiter le flux des paquets= =20 > r=C3=A9seaux au niveau de l'espace utilisateur. Bien que cela soit=20 > consid=C3=A9rablement plus facile que de faire de la programmation r=C3=A9s= eau=20 > dans le noyau, il reste cependant quelques d=C3=A9tails =C3=A0 prendre en c= ompte.=20 > Cet article vous guidera =C3=A0 travers mes trouvailles.=20 > IFF_TUN Versus IFF_TAP=20 > Le Pilote tun est un p=C3=A9riph=C3=A9rique deux-en-un:=20 > Un P=C3=A9riph=C3=A9rique point =C3=A0= point=20 > (IFF_TUN). Le p=C3=A9riph=C3=A9rique TUN permet le traitement de paquets IP= .=20 > Un p=C3=A9riph=C3=A9rique Ethernet (IFF_T= AP). Le=20 > p=C3=A9riph=C3=A9rique TAP traite les trames Ethernet.=20 > Cet article parle du code =C3=A0=20 > =C3=A9crire pour le p=C3=A9riph=C3=A9rique Ethernet.Si vous choisissez le p= =C3=A9riph=C3=A9rique=20 > IP, alors vous g=C3=A9n=C3=A8rerez 18 octets par paquet trait=C3=A9; le tra= fic est=20 > certes moins important (l'en-t=C3=AAte et la queue du paquet Ethernet), mai= s=20 > vous aurez =C3=A0 coder un peu plus pour mettre en place votre r=C3=A9seau.= =20 > Activation du pilote=20 > Premi=C3=A8rement, on doit s'assurer que le pilote tun est=20 > actif.Sur mon syst=C3=A8me Debian, je dois tout simplement le charger:=20 > # /sbin/modprobe tun # /sbin/lsmod | grep tun tun =20 > 10208 0 # /bin/ls -l /dev/net/tun crw-rw-rw- 1 root root=20 > 10, 200 2008-02-10 11:30 /dev/net/tun role=3D'strong'>La Configuration Pour des besoins=20 > de d=C3=A9monstration, on mettra en place un r=C3=A9seau virtuel de deux h= =C3=B4tes.=20 > Une fois qu'on a mis la main sur les paquets Ethernet, nous utiliserons=20 > l'encapsulation UDP pour les faire transiter d'une interface virtuelle=20 > sur l'h=C3=B4te A vers une interface virtuelle sur l'h=C3=B4te B et vice-ve= rsa. Le=20 > socket UDP sera utilis=C3=A9 en mode non-connect=C3=A9; cela a l'avantage d= e nous=20 > permettre d'utiliser le m=C3=AAme socket pour envoyer et recevoir des paque= ts=20 > depuis n'importe quel autre h=C3=B4te de notre r=C3=A9seau virtuel. Toutefo= is, la=20 > nature non-connect=C3=A9e de notre socket UDP, complique la r=C3=A9ception = du=20 > chemin MTU (plus de d=C3=A9tails dessus dans les prochaines lignes).=20 > Chaque h=C3=B4te de notre r=C3=A9seau virtuel ex=C3=A9cutera u= ne instance=20 > du programme de d=C3=A9monstration. Pour l'illustrer, le trafic d'une=20 > application (telnet dans le cas pr=C3=A9sent) sur l'h=C3=B4te A vers l'appl= ication=20 > correspondante (inetd/telnetd) vers l'h=C3=B4te B, utilisera le chemin=20 > suivant: Le m=C3=A9canisme de=20 > d=C3=A9couverte En pratique, nous avons besoin d'un= =20 > m=C3=A9canisme pour faire correspondre les adresses IP virtuelles aux=20 > adresses IP r=C3=A9elles. Il nous appartient de bidouiller une m=C3=A9thode= de=20 > d=C3=A9couverte pour r=C3=A9soudre ce probl=C3=A8me de correspondance; cepe= ndant comme=20 > cela n'est pas en rapport direct avec notre sujet du jour, ni n=C3=A9cessai= re=20 > pour les besoins de notre petite d=C3=A9monstration d=C3=A9crite ici, nous = allons=20 > tricher et laisser le programme de tunnelling =C3=A9tablir les=20 > correspondances par des lignes de commande:=20 > Host A# ./udptun=20 > Usage: ./udptun local-tun-ip remote-physical-ip Host A# ./udptun=20 > 172.16.0.1 192.168.2.103 Host B# ./udptun 172.16.0.111 192.168.2.113=20 > Mise en=20 > place de l'interface La premi=C3=A8re chose =C3=A0 = faire=20 > est de cr=C3=A9er l'interface Ethernet virtuelle (tap). Cela se fait avec u= n=20 > simple appel =C3=A0 la fonction open(): ifr_tun; > int fd; >=20 > if ((fd =3D open("/dev/net/tun", O_RDWR)) < 0) { > /*Erreur de traitement, retour.*/; > } >=20 > memset( &ifr_tun, 0, sizeof(ifr_tun) ); > ifr_tun.ifr_flags =3D IFF_TAP | IFF_NO_PI; > if ((ioctl(fd, TUNSETIFF, (void *)&ifr_tun)) < 0) { > /*Erreur de traitement, retour.*/; > } >=20 > /*Configurer l'interface: D=C3=A9finir l'adresse IP, le MTU,=20 > etc*/]]>Ici, l'indicateur IFF_NO_PI requiert qu'on=20 > manipule de trames brutes. Si on ne fait pas cela, les trames se verront=20 > ajouter un en-t=C3=AAte de 4 octets. role=3D'strong'>Interface setup: the IP address=20 > L'interface virtuelle doit =C3=AAtre identifi=C3=A9e par une a= dresse=20 > IP. On la d=C3=A9finira avec un appel de la fonction ioctl():=20 > int set_ip(struct ifreq *ifr_tun, unsigned long ip4) > { > struct sockaddr_in addr; > int sock =3D -1; >=20 > sock =3D socket(AF_INET, SOCK_DGRAM, 0); >=20 > if (sock < 0) { > /*Erreur de traitement, retour*/ > } >=20 > memset(&addr, 0, sizeof(addr)); > addr.sin_addr.s_addr =3D ip; /*network byte order*/ > addr.sin_family =3D AF_INET; > memcpy(&ifr_tun->ifr_addr, &addr, sizeof(struct sockaddr)); >=20 > if (ioctl(sock, SIOCSIFADDR, ifr_tun) < 0) { > /*Erreur de traitement, retour*/ > } >=20 > /*Sera Utilis=C3=A9 plus tard pour d=C3=A9finir le MTU.*/ > return sock; > }]]>Le PMTU (Path Maximum=20 > Transmission Unit) La seul =C3=A9l=C3=A9ment que no= us=20 > avons =C3=A0 configurer est le MTU (Maximum Transmit Unit) de l'interface. = > Pour notre interface pseudo-Ethernet, le MTU est la charge la plus=20 > importante que les trames Ethernet peuvent transporter. On d=C3=A9finira le= =20 > PMTU en fonction du MTU. Pour faire simple, on dira que le=20 > PMTU est le paquet le plus large qui peut traverser le chemin allant=20 > d'un h=C3=B4te =C3=A0 sa destination sans subir de fragmentation. Le=20 > PMTU est un param=C3=A8tre important =C3=A0 prendre en compte pour que tout= se=20 > passe bien. Consid=C3=A9rez ceci: en (r=C3=A9)injectant vos trames dans le = noyau,=20 > elles se verront attribuer des en-t=C3=AAtes (IP, UDP et Ethernet)=20 > suppl=C3=A9mentaires. Si la taille de la trame que vous avez envoy=C3=A9e a= u noyau=20 > est trop proche du PMTU, la trame finale qui sera envoy=C3=A9e =C3=A0 parti= r de=20 > l'interface r=C3=A9elle pourrait =C3=AAtre plus grande que le PMTU. Au pire= des=20 > cas, une telle trame sera perdue quelque part en route. Au meilleur des=20 > cas, la trame sera fragment=C3=A9e en deux et la premi=C3=A8re partie sera = trait=C3=A9e=20 > =C3=A0 100%, ce qui ne sera pas le cas pour la seconde partie.=20 > Pour =C3=A9viter cela, on doit d=C3=A9couvrir la valeur du PMT= U et=20 > s'assurer que la nouvelle trame Ethernet sera correctement dimensionn=C3=A9= e=20 > pour le PMTU. Ensuite, on soustraira du PMTU la taille des nouvelles=20 > en-t=C3=AAtes et on donnera cette valeur au MTU de l'interface virtuelle.=20 > La t=C3=A2che est facile sous Linux, pour un socket TCP: on do= it=20 > juste s'assurer que les m=C3=A9canismes de d=C3=A9couverte du PMTU par le n= oyau=20 > sont configur=C3=A9s, et c'est tout. Par contre pour les socke= ts=20 > UDP, nous les utilisateurs, avons la responsabilit=C3=A9 de nous assurer qu= e=20 > les datagrammes UDP sont de taille correcte. Si le socket UDP est=20 > connect=C3=A9 =C3=A0 l'h=C3=B4te correspondant, un simple appel appel de la= fonction=20 > getsockopt()avec l'indicateur IP_MTU positionn=C3=A9, nous donnera le PMTU = > En ce qui concerne les sockets non-connect=C3=A9s, on doit=20 > analyser le PMTU. Premi=C3=A8rement, le socket doit =C3=AAtre configur=C3= =A9 de fa=C3=A7on =C3=A0=20 > ce que les datagrammes ne soient pas fragment=C3=A9s (positionner=20 > l'indicateur DF); ensuite, on doit configurer de fa=C3=A7on =C3=A0 =C3=AAtr= e averti des=20 > erreurs ICMP que cela pourrait g=C3=A9n=C3=A9rer. Si un h=C3=B4te ne peut p= as g=C3=A9rer la=20 > taille du datagramme sans le fragmenter, alors il devra nous en informer=20 > (enfin, on l'esp=C3=A8re): int on; >=20 > sock =3D socket(AF_INET, SOCK_DGRAM, 0); > if (sock < 0) { > /*Erreur de traitement, retour*/; > } >=20 > on =3D IP_PMTUDISC_DO; > if (setsockopt(sock, SOL_IP, IP_MTU_DISCOVER, &on, sizeof(on))) { > /*Erreur de traitement, retour*/; > } >=20 > on =3D 1; > if (setsockopt(sock, SOL_IP, IP_RECVERR, &on, sizeof(on))) { > /*Erreur de traitement, retour*/; > } >=20 > /*Utiliser sock pour la d=C3=A9couverte du=20 > PMTU.*/]]>Ensuite, on envoie des datagrammes analys=C3=A9s d= e=20 > diverses tailles: buf, len, 0, > (struct sockaddr*)target, > sizeof(struct sockaddr_in));]]>Pour=20 > finir, on farfouille parmi les erreurs jusqu'=C3=A0 trouver le bon PMTU. Si= =20 > on a une erreur de PMTU, on ajuste la taille du datagramme et on=20 > recommence =C3=A0 envoyer les datagrammes jusqu'=C3=A0 ce que la destinatio= n soit=20 > atteinte: struct iovec iov; > struct msghdr msg; > struct cmsghdr *cmsg =3D NULL; > struct sock_extended_err *err =3D NULL; > struct sockaddr_in addr; > int res; > int mtu; >=20 > if (recv(sock, sndbuf, sizeof(sndbuf), MSG_DONTWAIT) > 0) { > /* R=C3=A9ponse re=C3=A7ue. Fin de la d=C3=A9couverte du PMTU. Reto= ur.*/ > } >=20 > msg.msg_name =3D (unsigned char*)&addr; > msg.msg_namelen =3D sizeof(addr); > msg.msg_iov =3D &iov; > msg.msg_iovlen =3D 1; > msg.msg_flags =3D 0; > msg.msg_control =3D cbuf; > msg.msg_controllen =3D sizeof(cbuf); > res =3D recvmsg(sock, &msg, MSG_ERRQUEUE); > if (res < 0) { > if (errno !=3D EAGAIN) > perror("recvmsg"); > /*Nothing for now, return.*/ > } >=20 > for (cmsg =3D CMSG_FIRSTHDR(&msg); cmsg; cmsg =3D CMSG_NXTHDR(&msg,=20 > cmsg)) { > if (cmsg->cmsg_level =3D=3D SOL_IP) { > if (cmsg->cmsg_type =3D=3D IP_RECVERR) { > err =3D (struct sock_extended_err *) CMSG_DATA(cmsg); > } > } > } > if (err =3D=3D NULL) { > /*D=C3=A9couvrte du PMTU: pas d'info jusque l=C3=A0. Retour, mais c= ontinue=20 > =C3=A0 analyser.*/ > } >=20 >=20 > mtu =3D 0; > switch (err->ee_errno) { > ... > case EMSGSIZE: > debug(" EMSGSIZE pmtu %d\n", err->ee_info); > mtu =3D err->ee_info; > break; > ... > } /*end switch*/ >=20 > return mtu; /*Mais continue =C3=A0 analyser jusqu'=C3=A0 ce que l'h=C3= =B4te distant=20 > soit atteint!*/]]>Une derni=C3=A8re chose: le PMTU est tenu = de=20 > changer dans le temps. On devra donc le tester de temps en temps et=20 > ensuite configurer le MTU de l'interface virtuelle en fonction des=20 > r=C3=A9sultats du test. Si on veut =C3=A9viter toute cette gymnastique, on = peut=20 > configurer le MTU de fa=C3=A7on s=C3=A9curis=C3=A9e mais moins optimale : c= hoisir la=20 > valeur la plus petit entre 576 et le MTU de l'interface physique (moins=20 > l'en-t=C3=AAte que nous avons mentionn=C3=A9, bien entendu.)=20 > Configuration de l'interface: le=20 > MTU Apr=C3=A8s avoir finalement obtenu cette valeur= =20 > magique qu'est le PMTU, nous pouvons correctement configurer le MTU de=20 > notre interface: ... > ifr_tun->ifr_mtu =3D mtu; > if (ioctl(sock, SIOCSIFMTU, ifr_tun) < 0) { > /*Erreur de Traitement*/ > }]]>Encapsulation=20 > UDP Nous avons maintenant une interface=20 > virtuelle bien configur=C3=A9e et qui fonctionne. Tout ce que nous avons = =C3=A0=20 > faire est de relayer les trames dans les deux directions. Premi=C3=A8rement= ,=20 > il faut ouvrir un socket UDP non-connect=C3=A9 (Je vous =C3=A9pargne les d= =C3=A9tails),=20 > et ensuite: Lire = > les paquets du fichier descriptif du tap et les envoyer =C3=A0 l'adresse IP= =20 > physique distante de notre h=C3=B4te correspondant; ceci enverra les paquet= s=20 > dans une seule direction.=20 > buf[VPN_MAX_MTU] =3D {0}; > struct sockaddr_in cliaddr =3D {0}; > int recvlen =3D -1; > socklen_t clilen =3D sizeof(cliaddr); >=20 > recvlen =3D read(_tun_fd, buf, sizeof(buf)); > if (recvlen > 0) > sendto(_udp_fd, buf, recvlen, 0, (struct=20 > sockaddr*)&cliaddr, clilen); ]]> override=3D'none'>Avertissement:= =20 > La lecture du fichier descriptif du tap va provoquer un blocage. Cela=20 > veut dire que la fonction read() ne va pas =C3=AAtre interrompue m=C3=AAme = si on=20 > ferme le descripteur sous-jacent du fichier. On est donc oblig=C3=A9=20 > d'utiliser les fonctions poll()/select() sur ce descripteur de fichier=20 > avant d'executer la fonction read() dessus si on veut pouvoir terminer=20 > ce thread proprement.=20 > lire les=20 > datagrammes du socket UDP et les envoyer =C3=A0 travers le descripteur de=20 > fichier tap : les donn=C3=A9es circuleront maintenant dans la direction=20 > oppos=C3=A9e. recvfrom(_udp_fd, buf, sizeof(buf), 0, > (struct sockaddr*)&cliaddr, &clilen); > if (recvlen > 0) > write(_tun_fd, buf, recvlen); ]]>Notez=20 > qu'en pratique, si on a plus de deux h=C3=B4tes dans son r=C3=A9seau virtue= l, on=20 > doit regarder le contenu des trames pour v=C3=A9rifier les adresses IP sour= ce=20 > et destination avant de d=C3=A9cider o=C3=B9 envoyer la trame. On=20 > peut t=C3=A9l=C3=A9charger les sources des fichiers udptun.c, ttools.c, tto= ols.h=20 > et pathmtu.c avec le Makefile; tout ce dont on parl=C3=A9 ci-dessus est aus= si=20 > t=C3=A9l=C3=A9chargeable sous la forme d'une archive tar. role=3D'strong'>P comme Priv=C3=A9 Comme on a le=20 > contr=C3=B4le total du trafic de notre r=C3=A9seau virtuel, on peut le cryp= ter=20 > dans l'espace utilisateur. Pour les besoins de cette d=C3=A9monstration, no= us=20 > allons construire un VPN complet, que nous allons crypter avec IPSEC=20 > (remarque: IPSEC a aussi une fonctionnalit=C3=A9 int=C3=A9gr=C3=A9e de tunn= elling).=20 > Sous Debian, il faut juste installer le paquetage=20 > ipsec-tools et utiliser ces fichiers pour des manipulations manuelles:=20 > Pour l'h=C3=B4te A: override=3D'none'>## Vider le SAD et SPD flush; spdflush;=20 > # A & B add 172.16.0.1 172.16.0.111 ah 15700 -A=20 > hmac-md5 "123456789.123456"; add 172.16.0.111 172.16.0.1 ah 24500=20 > -A hmac-md5 "123456789.123456"; add 172.16.0.1 172.16.0.111 esp=20 > 15701 -E 3des-cbc "123456789.123456789.1234"; add 172.16.0.111=20 > 172.16.0.1 esp 24501 -E 3des-cbc "123456789.123456789.1234"; # A=20 > spdadd 172.16.0.1 172.16.0.111 any -P out ipsec=20 > override=3D'none'>esp/transport//require ah/transport//require;=20 > spdadd 172.16.0.111 172.16.0.1=20 > any -P in ipsec override=3D'none'>esp/transport//require ah/transport//require;=20 > Pour=20 > l'h=C3=B4te B: ## Vi= der=20 > le SAD et SPD flush; spdflush; # A & B add 172.16.0.1 =20 > 172.16.0.111 ah 15700 -A hmac-md5 "123456789.123456"; add=20 > 172.16.0.111 172.16.0.1 ah 24500 -A hmac-md5 "123456789.123456"; add=20 > 172.16.0.1 172.16.0.111 esp 15701 -E 3des-cbc=20 > override=3D'none'>"123456789.123456789.1234";=20 > add 172.16.0.111 172.16.0.1 esp=20 > 24501 -E 3des-cbc override=3D'none'>"123456789.123456789.1234";=20 > #dump ah; #dump esp; # B spdadd=20 > 172.16.0.111 172.16.0.1 any -P out ipsec override=3D'none'>esp/transport//require ah/transport//require;=20 > spdadd 172.16.0.1 172.16.0.111=20 > any -P in ipsec override=3D'none'>esp/transport//require ah/transport//require;=20 > Remarquez = > comme le m=C3=A9canisme de cryptage tout entier est li=C3=A9 aux adresses=20 > virtuelles et comme il vous isole des r=C3=A9seaux physiques sur lesquels v= os=20 > h=C3=B4tes se trouvent. Vous pouvez directement t=C3=A9l=C3=A9charger le fi= chier=20 > ipsec-tools.conf. Le VPN en=20 > marche C'est parti! Faisons un ping de 100=20 > octets sur l'interface virtuelle de l'autre h=C3=B4te:=20 > Host A$ ping -s 100 = > 172.16.0.111 Regardons le trafic=20 > avec tcpdump sur l'interface virtuelle:: override=3D'none'>#tcpdump -i tap0 override=3D'none'>.. 15:43:27.739218 IP 172.16.0.1 >=20 > 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1d):=20 > override=3D'none'>ESP(spi=3D0x00003d55,seq=3D0x1d), length role=3D'strong'>128=20 > 15:43:27.740673 IP 172.16.0.111 >=20 > 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1d): override=3D'none'>ESP(spi=3D0x00005fb5,seq=3D0x1d), length 128=20 > 15:43:28.738741 IP 172.16.0.1 >=20 > 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1e):=20 > override=3D'none'>ESP(spi=3D0x00003d55,seq=3D0x1e), length 128=20 > 15:43:28.740170 IP 172.16.0.111 >=20 > 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1e): override=3D'none'>ESP(spi=3D0x00005fb5,seq=3D0x1e), length 128=20 > 15:43:39.494298 IP 172.16.0.1 >=20 > 172.16.0.111: AH(spi=3D0x00003d54,seq=3D0x1f):=20 > override=3D'none'>ESP(spi=3D0x00003d55,seq=3D0x1f), length 64=20 > 15:43:39.496818 IP 172.16.0.111 >=20 > 172.16.0.1: AH(spi=3D0x00005fb4,seq=3D0x1f): override=3D'none'>ESP(spi=3D0x00005fb5,seq=3D0x1f), length 40=20 > Sur=20 > l'interface physique: override=3D'none'># tcpdump -i eth2 override=3D'none'>.. 15:45:46.878156 IP=20 > 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 > length role=3D'strong'>186=20 > 15:45:46.879021 IP=20 > 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 > length 186=20 > 15:45:47.879479 IP=20 > 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 > length 186=20 > 15:45:47.887054 IP=20 > 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 > length 186=20 > 15:45:48.880268 IP=20 > 192.168.40.128.11223 > 192.168.40.129.11223: UDP,=20 > length 186=20 > 15:45:48.882738 IP=20 > 192.168.40.129.11223 > 192.168.40.128.11223: UDP,=20 > length 186=20 > Tous=20 > les chiffres en gras sont des charges utiles. Quand il sort de=20 > l'interface virtuelle, le datagramme crypt=C3=A9 est de 186 octets: 14 octe= ts=20 > pour l'en-t=C3=AAte Ethernet, 20 pour l'en-t=C3=AAte IP, un en-t=C3=AAte AH= de 24=20 > octets et un ESP pour les 128 octets restants. Quand il=20 > sort de l'interface physique, le datagramme est de 232 octets: 14 octets=20 > pour l'en-t=C3=AAte Ethernet, 20 octets pour l'en-t=C3=AAte IP, 8 pour l'en= -t=C3=AAte=20 > UDP, 186 octets de charge physique et 4 octets pour le bloc de fin de la=20 > trame Ethernet. Nous avons donc rajout=C3=A9 46 octets par datagramme.=20 > Ressources=20 > url=3D'http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt'>= The=20 > TUN/TAP kernel documentation=20 > url=3D'http://www.faqs.org/rfcs/rfc1191.html'>The Path MTU Discovery=20 > RFC url=3D'http://linux.die.net/man/7/ip'>The Linux IPv4 man page=20 > url=3D'http://www.networksorcery.com/enp/Protocol.htm'>The RFC=20 > Sourcebook

=20 >=20 >=20 --=20 --===============6246833100734054150== Content-Type: text/xml Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lg160-A.xml" MIME-Version: 1.0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIGFydGljbGUg UFVCTElDICItLy9PQVNJUy8vRFREIERvY0Jvb2sgWE1MIFY0LjUvL0VOIgogICJodHRwOi8vd3d3 Lm9hc2lzLW9wZW4ub3JnL2RvY2Jvb2sveG1sLzQuNS9kb2Nib29reC5kdGQiPgoKCjxhcnRpY2xl IGxhbmc9ImZyIj4KCiA8YXJ0aWNsZWluZm8+CiAgPHRpdGxlPk1lcyBhc3R1Y2VzPC90aXRsZT4K CiAgPHN1YnRpdGxlPgogIEdhemV0dGUmbmJzcDtMaW51eCBu77+977+9MTYwJm5ic3A7Jm1kYXNo OyZuYnNwO01hcnMmbmJzcDsyMDA5CiAgPC9zdWJ0aXRsZT4KCiAgPGF1dGhvcj4KICAgIDxmaXJz dG5hbWU+QmVuPC9maXJzdG5hbWU+CiAgICA8c3VybmFtZT5Pa29wbmlrPC9zdXJuYW1lPgogICAg PGVtYWlsPmJlbiBDSEVaIGxpbnV4Z2F6ZXR0ZSBQT0lOVCBuZXQ8L2VtYWlsPgogIDwvYXV0aG9y PgoKICA8b3RoZXJjcmVkaXQgcm9sZT0idHJhZHVjdGlvbiIgY2xhc3M9InRyYW5zbGF0b3IiPgog ICAgIDxmaXJzdG5hbWU+RGVueTwvZmlyc3RuYW1lPgogICAgICAgPGNvbnRyaWI+QWRhcHRhdGlv biBmcmFu77+977+9YWlzZSA8L2NvbnRyaWI+CiAgICAgPGVtYWlsPmRlbnkgQ0hFWiBtb25hY28g UE9JTlQgbmV0PC9lbWFpbD4KICA8L290aGVyY3JlZGl0PgoKICA8b3RoZXJjcmVkaXQgcm9sZT0i cmVsZWN0dXJlIiBjbGFzcz0idHJhbnNsYXRvciI+CiAgICA8Zmlyc3RuYW1lPjwvZmlyc3RuYW1l PgogICAgPHN1cm5hbWU+PC9zdXJuYW1lPgogICAgPGNvbnRyaWI+UmVsZWN0dXJlIGRlIGxhIHZl cnNpb24gZnJhbu+/ve+/vWFpc2UgPC9jb250cmliPgogICAgPGVtYWlsPjwvZW1haWw+CiAgPC9v dGhlcmNyZWRpdD4KCiAgPGxlZ2Fsbm90aWNlPgogICAgPHBhcmE+QXJ0aWNsZSBwYXJ1IGRhbnMg bGUgbu+/ve+/vTE2MCBkZSBsYSBHYXpldHRlIExpbnV4IGRlIE1hcnMgMjAwOS48L3BhcmE+CiAg ICA8cGFyYT5BcnRpY2xlIHB1Ymxp77+977+9IHNvdXMgPHVsaW5rIHVybD0iaHR0cDovL2xpbnV4 Z2F6ZXR0ZS5uZXQvY29weWluZy5odG1sIj5PcGVuIFB1YmxpY2F0aW9uIExpY2Vuc2U8L3VsaW5r Pi4gTGEgPGNpdGV0aXRsZT5MaW51eCBHYXpldHRlPC9jaXRldGl0bGU+IG4nZXN0IG5pIHByb2R1 aXRlLCBuaSBzcG9uc29yaXPvv73vv71lLCBuaSBhdmFsaXPvv73vv71lIHBhciBub3RyZSBo77+9 77+9YmVyZ2V1ciBwcmluY2lwYWwsIFNTQywgSW5jLjwvcGFyYT4KICA8L2xlZ2Fsbm90aWNlPgoK ICA8Y29weXJpZ2h0PgogICAgPHllYXI+MjAwOTwveWVhcj4KICAgIDxob2xkZXI+QmVuIE9rb3Bu aWs8L2hvbGRlcj4KICA8L2NvcHlyaWdodD4KCiAgPGNvcHlyaWdodD4KICAgIDx5ZWFyPjIwMDk8 L3llYXI+CiAgICA8aG9sZGVyPkRlbnk8L2hvbGRlcj4KICA8L2NvcHlyaWdodD4KCiAgCiA8L2Fy dGljbGVpbmZvPgogCiA8c2VjdGlvbiBpZD0ibGVjdHVyZSI+PHRpdGxlPkxpcmUgZGVzIGZpY2hp ZXJzIDxhY3JvbnltPk1IVDwvYWNyb255bT4gc291cyA8c3lzdGVtaXRlbSBjbGFzcz0ib3NuYW1l Ij5MaW51eDwvc3lzdGVtaXRlbT48L3RpdGxlPgo8cGFyYT4KQWJvcmRvbnMgdW4gYXV0cmUgZm9y bWF0IHByb3Byae+/ve+/vXRhaXJlIG9yaWdpbmFpcmUgZGUgPHRyYWRlbWFyayBjbGFzcz0iY29w eXJpZ2h0Ij5NaWNyMHMwZnQ8L3RyYWRlbWFyaz4mbmJzcDs6IGxlcyBmaWNoaWVycyA8YWNyb255 bT4ubWh0PC9hY3JvbnltPi4gSWwgc2VtYmxlIHF1ZSA8YXBwbGljYXRpb24+SW50ZXJuZXQgRXhw bG9yZXI8L2FwcGxpY2F0aW9uPiBlbnJlZ2lzdHJlIGxlcyBjb3VycmllbHMgZXQgPGFjcm9ueW0+ SFRNTDwvYWNyb255bT4gZCd1bmUgbWFuae+/ve+/vXJlIGhhc2FyZGV1c2UgcXVpIHJlc3NlbWJs ZSBhc3NleiBwZXUg77+977+9IHVuIGNvdXJyaWVsJm5ic3A7OyBzZWxvbiBXaWtpcGVkaWEsIGls IG4nZXhpc3RlIHBhcyBkZSBub3JtZSB1bmlxdWUsIGV0IGxhIHNpdHVhdGlvbiBlc3QgZO+/ve+/ vWNyaXRlIGNvbW1lIDxxdW90ZT5wcm9ibO+/ve+/vW1hdGlxdWU8L3F1b3RlPi4KPC9wYXJhPgoK PHBhcmE+ClVuZSByZWNoZXJjaGUgPGFwcGxpY2F0aW9uPkludGVybmV0PC9hcHBsaWNhdGlvbj4g bW9udHJlIHF1J2lsIHkgYSBkZSBub21icmV1c2VzIHBlcnNvbm5lcyZtZGFzaDtsZXMgZO+/ve+/ vWJ1dGFudHMgZnJh77+977+9Y2hlbWVudCBjb252ZXJ0aXMg77+977+9IDxzeXN0ZW1pdGVtIGNs YXNzPSJvc25hbWUiPkxpbnV4PC9zeXN0ZW1pdGVtPiBlbiBwYXJ0aWN1bGllciZtZGFzaDtxdWkg cG9zc++/ve+/vWRlbnQgbm9tYnJlIGRlIGNlcyBmaWNoaWVycyBldCBuZSBzYXZlbnQgcXVvaSBl biBmYWlyZS4gQ2VydGFpbnMgcmVjb21tYW5kZW50IDxhcHBsaWNhdGlvbj5PcGVyYTwvYXBwbGlj YXRpb24+IChqZSBzdXBwb3NlIHF1ZSBxdWVscXVlcyBoZXVyZXMgZW4gY29tcGFnbmllIGRlIEtp cmkgVGUgS2FuYXdhIHNvdWxhZ2VudCB0b3V0ZXMgc29ydGVzIGRlIHN0cmVzcyZuYnNwOy4uLikm bmJzcDs7IGQnYXV0cmVzIG9udCBldSBkZSBsYSBjaGFuY2UgYXZlYyBkaXZlcnMgdXRpbGl0YWly ZXMgZGUgY29udmVyc2lvbi4gSmUgbSd5IHN1aXMgaW5077+977+9cmVzc++/ve+/vSwgZXQgY2Vs YSByZXNzZW1ibGFpdCDvv73vv70gdW4gZW4tdO+/ve+/vXRlIGRlIGNvdXJyaWVyIGTvv73vv71m ZWN0dWV1eC4KPC9wYXJhPgoKPHBhcmE+CkplIG5lIHN1aXMgcGFzIGFsbO+/ve+/vSByZWNoZXJj aGVyIGF1LWRlbO+/ve+/vSBkdSBzZXVsIGZpY2hpZXIgcXVlIGplIHBvc3Pvv73vv71kZSwgbWFp cyB2b2ljaSBjZSBxdWkgZm9uY3Rpb25uZSBjb3JyZWN0ZW1lbnQgcXVhbmQgamUgbCdvdXZyZSZu YnNwOzogCjwvcGFyYT4KCjxwcm9ncmFtbGlzdGluZz4KIyBDb252ZXJ0aXQgbGVzIGZpbnMgZGUg bGlnbmUgYXUgZm9ybWF0IFVuaXgKZmxpcCAtdWIgZmlsZS5taHQKIyBBam91dGUgdW4gZW4tdO+/ ve+/vXRlIGRlIGNvdXJyaWVyIHN0YW5kYXJkICdGcm9tICcgYXUgZmljaGllcgpzZWQgLWkgJzFp XCciJChlY2hvIEZyb20gJFVTRVIgJChkYXRlKSkiIGZpbGUubWh0CiMgVm91cyBkZXZyaWV6IO+/ ve+/vSBwcu+/ve+/vXNlbnQgcG91dm9pciBsJ291dnJpciBhdmVjIHZvdHJlIE1VQSBmYXZvcmkK bXV0dCAtZiBmaWxlLm1odAo8L3Byb2dyYW1saXN0aW5nPgoKPC9zZWN0aW9uPgoKPHNlY3Rpb24g aWQ9InJhcHBlbCI+PHRpdGxlPiAgICBSYXBwZWxzIGdyYXR1aXRzIGV0IHJhcGlkZXMgc3VyIHZv dHJlIHTvv73vv71s77+977+9cGhvbmUgcG9ydGFibGU8L3RpdGxlPgo8cGFyYT4KQ2VjaSBuZSBj b25jZXJuZSBwYXMgdnJhaW1lbnQgPHN5c3RlbWl0ZW0gY2xhc3M9Im9zbmFtZSI+TGludXg8L3N5 c3RlbWl0ZW0+LCBtYWlzIGMnZXN0IHVuZSBhc3R1Y2UgaW5077+977+9cmVzc2FudGUgY2VwZW5k YW50Lgo8L3BhcmE+CjxwYXJhPgpTaSB2b3VzIHV0aWxpc2V6IHVuZSBwYWdlIGQnZW52b2kgZCd1 biBjb3VycmllbCDvv73vv70gdW5lIGRhdGUgdWx077+977+9cmlldXJlICh0ZWxsZSBxdWUgPHVs aW5rIHVybD0iaHR0cDovL3d3dy5mdXR1cmVtZS5vcmcvIj5odHRwOi8vd3d3LmZ1dHVyZW1lLm9y Zy88L3VsaW5rPikgZW4gZW52b3lhbnQgY29uam9pbnRlbWVudCB1biBjb3VycmllbCB2ZXJzIHVu ZSBwYXNzZXJlbGxlIDxhY3JvbnltPnNtczwvYWNyb255bT4gKHZvdXMgcG91dmV6IG9idGVuaXIg dW5lIGxpc3RlIGljaSZuYnNwOzogPHVsaW5rIHVybD0iaHR0cDovL3d3dy5tdXR1YmUuY29tL3By b2plY3RzL29wZW4tZW1haWwtdG8tc21zL2dhdGV3YXktbGlzdC8iPmh0dHA6Ly93d3cubXV0dWJl LmNvbS9wcm9qZWN0cy9vcGVuLWVtYWlsLXRvLXNtcy9nYXRld2F5LWxpc3QvPC91bGluaz4gKSwg dm91cyBwb3V2ZXogZW52b3llciBkZXMgcmFwcGVscyBkZSBmYe+/ve+/vW9uIGxpYnJlIGV0IHJh cGlkZSwgZGlyZWN0ZW1lbnQgc3VyIHZvdHJlIHTvv73vv71s77+977+9cGhvbmUgcG9ydGFibGUg KGV0IGZ1dHVyZW1lIG5lIHZvdXMgZGVtYW5kZSBt77+977+9bWUgcGFzIGRlIHZvdXMgZW5yZWdp c3RyZXIpIAo8L3BhcmE+Cjwvc2VjdGlvbj4KCgo8c2VjdGlvbiBpZD0iaW1hZ2VzIj48dGl0bGU+ ICAgQ29udmVyc2lvbiBkZSBwb2xpY2VzIGRlIGNhcmFjdO+/ve+/vXJlcyBlbiBpbWFnZXM8L3Rp dGxlPgo8cGFyYT4KVm91cyBuZSBsZSBzYXZleiBwZXV0Le+/ve+/vXRyZSBwYXMsIG1haXMgbGVz IGZpY2hpZXJzIDx0cmFkZW1hcmsgY2xhc3M9ImNvcHlyaWdodCI+VHJ1ZVR5cGU8L3RyYWRlbWFy az4gcGV1dmVudCDvv73vv710cmUgdmlzdWFsaXPvv73vv71zIGF2ZWMgbCdhcHBsaWNhdGlvbiA8 YXBwbGljYXRpb24+ZGlzcGxheTwvYXBwbGljYXRpb24+Jm1kYXNoO2NvbW1lIHMnaWwgcydhZ2lz c2FpdCBkJ3VuIGF1dHJlIHR5cGUgZCdpbWFnZS4KPC9wYXJhPgo8cHJvZ3JhbWxpc3Rpbmc+CiNj b252ZXJ0aXIgZm9udF9uYW1lLnR0ZiBlbiBmb250X25hbWUudHRmLmpwZwojaWwgcydhZ2l0IGVu IGfvv73vv71u77+977+9cmFsIGQndW4gZmljaGllciBub21t77+977+9IHR0Zi1jb252ZXJ0Cgog IyEvYmluL2Jhc2gKIHdoaWxlIFsgJCMgLWd0IDAgXTsKIGRvCiBjb252ZXJ0ICQxICQxLmpwZwo8 L3Byb2dyYW1saXN0aW5nPgo8cGFyYT4KTCdvcO+/ve+/vXJhdGlvbiDvv73vv71jaG91ZXJhIG5h dHVyZWxsZW1lbnQsIHNpIGxlIGZpY2hpZXIgZXN0IG5vbW3vv73vv70gPGZpbGVuYW1lPk1TIFZl cmRhbmEudHRmPC9maWxlbmFtZT4sIChub3RleiBsJ2VzcGFjZS4pLiBJbCBlc3QgdG91am91cnMg cHLvv73vv71m77+977+9cmFibGUgZGUgbWV0dHJlIGVuIGd1aWxsZW1ldHMgbGVzIHZhcmlhYmxl cyBlbXBsb3nvv73vv71lcyBlbiBhcmd1bWVudC4KPC9wYXJhPgo8cHJvZ3JhbWxpc3Rpbmc+Cj4g c2hpZnQ7Cj4gZG9uZQo8L3Byb2dyYW1saXN0aW5nPgo8cGFyYT4KSidhaSBwZXVyIHF1ZSBjZSBz b2l0IHVuIG1hdXZhaXMgb3V0aWwgcG91ciBjZSBnZW5yZSBkZSB0cmF2YWlsLiBVbmUgYm91Y2xl IDxjb21tYW5kPndoaWxlPC9jb21tYW5kPiBlc3QgdW4gdGVzdGV1ciBkJ++/ve+/vXRhdCAoYydl c3Qt77+977+9LWRpcmUsIGVsbGUgdu+/ve+/vXJpZmllIHNpIGwn77+977+9dGF0IGVzdCB2cmFp IG91IGZhdXggZXQgZWxsZSBib3VjbGUpJm5ic3A7OyBsYSBib3VjbGUgPGNvbW1hbmQ+Zm9yPC9j b21tYW5kPiBlc3QgdW4gaXTvv73vv71yYXRldXIsIHF1aSBwYXJjb3VydCAoPGZvcmVpZ25waHJh c2U+aXRlcmF0ZXM8L2ZvcmVpZ25waHJhc2U+KSB1bmUgbGlzdGUgZCdhcmd1bWVudHMmbWRhc2g7 Y2UgcXVpIGVzdCBleGFjdGVtZW50IGNlIHF1ZSBsJ29uIGRlbWFuZGUgaWNpLiAKPC9wYXJhPgo8 cHJvZ3JhbWxpc3Rpbmc+CiMgQm91Y2xlIHN1ciBsYSBsaXN0ZSBkZSB0b3VzIGxlcyBhcmd1bWVu dHMgZW4gbGlnbmUgZGUgY29tbWFuZGUKZm9yIGYKZG8KCS91c3IvYmluL2NvbnZlcnQgIiRmIiAi JGYuanBnIgpkb25lCjwvcHJvZ3JhbWxpc3Rpbmc+CjxwYXJhPgombmJzcDsuLi5tYWlzLCBwdWlz cXUnaWwgcydhZ2l0IHZyYWltZW50IGQndW5lIGNvbW1hbmRlIGQndW5lIGxpZ25lLCBqJ2F1cmFp cyBwbHV077+977+9dCB0ZW5kYW5jZSDvv73vv70gc2Fpc2lyJm5ic3A7CjwvcGFyYT4KPHByb2dy YW1saXN0aW5nPgpmb3IgZiBpbiAqdHRmOyBkbyBjb252ZXJ0ICIkZiIgIiRmLmpwZyI7IGRvbmUK PC9wcm9ncmFtbGlzdGluZz4KPHBhcmE+CmVuIGxpZ25lIGRlIGNvbW1hbmRlLgo8L3BhcmE+Cjwv c2VjdGlvbj4KCjxzZWN0aW9uIGlkPSJpbmRleGF0aW9uIj48dGl0bGU+CVVuZSBtYW5p77+977+9 cmUgZmFjaWxlIGRlIHPvv73vv71jdXJpc2VyIGRldXggZmljaGllcnMgb3Ugcu+/ve+/vXBlcnRv aXJlcyBleGFjdGVtZW50IHNlbWJsYWJsZXM8L3RpdGxlPgoKPHBhcmE+ClNpIHZvdXMgYWRtaW5p c3RyZXogdW4gc3lzdO+/ve+/vW1lIDxzeXN0ZW1pdGVtIGNsYXNzPSJvc25hbWUiPkxpbnV4PC9z eXN0ZW1pdGVtPiBhdmVjIHVuZSBwb2xpdGlxdWUgPGFwcGxpY2F0aW9uPlNFTGludXg8L2FwcGxp Y2F0aW9uPiByZW5mb3Jj77+977+9ZSwgdm91cyBzYXZleiBxdWUgbGEgcGx1cGFydCBkdSB0ZW1w cywgdm91cyBkZXZleiBk77+977+9ZmluaXIgdW5lIHBvbGl0aXF1ZSBkZSBz77+977+9Y3VyaXTv v73vv70gcG91ciBjZXJ0YWlucyBmaWNoaWVycyBvdSBy77+977+9cGVydG9pcmVzIGFmaW4gcXVl IGxlcyBk77+977+9bW9ucyBvdSBsZXMgdXRpbGlzYXRldXJzIHB1aXNzZW50IGNvcnJlY3RlbWVu dCB5IGFjY++/ve+/vWRlci4KPC9wYXJhPgo8cGFyYT4KU2kgbGEgdO+/ve+/vWNoZSByZXNzZW1i bGUg77+977+9IDxxdW90ZT5KZSBjcu+/ve+/vWUgdW4gbm91dmVhdSBy77+977+9cGVydG9pcmUg PGZpbGVuYW1lIGNsYXNzPSJkaXJlY3RvcnkiPi92YXIvYXBhY2hlL2h0bWw8L2ZpbGVuYW1lPiBw b3VyIHBsYWNlciBkZXMgZmljaGllcnMgPGFjcm9ueW0+SFRNTDwvYWNyb255bT4gcG91ciBtb24g bm91dmVsIGjvv73vv710ZSB2aXJ0dWVsIHNvdXMgPGFwcGxpY2F0aW9uPkFwYWNoZTwvYXBwbGlj YXRpb24+PC9xdW90ZT4sIHZvdXMgZGV2ZXog77+977+9dGFibGlyIGxhIG3vv73vv71tZSBwb2xp dGlxdWUgZGUgc++/ve+/vWN1cml077+977+9IHBvdXIgPGZpbGVuYW1lIGNsYXNzPSJkaXJlY3Rv cnkiPi92YXIvYXBhY2hlL2h0bWw8L2ZpbGVuYW1lPiBxdWUgcG91ciA8ZmlsZW5hbWUgY2xhc3M9 ImRpcmVjdG9yeSI+L3Zhci93d3cvaHRtbDwvZmlsZW5hbWU+IChlbiBzdXBwb3NhbnQgcXUnaWwg cydhZ2l0IGR1IHLvv73vv71wZXJ0b2lyZSByYWNpbmUgPGZvcmVpZ25waHJhc2U+RG9jdW1lbnRS b290PC9mb3JlaWducGhyYXNlPiBwYXIgZO+/ve+/vWZhdXQgZCc8YXBwbGljYXRpb24+QXBhY2hl PC9hcHBsaWNhdGlvbj4pLiBDZXR0ZSBjb21tYW5kZSBmYWl0IGxlIG7vv73vv71jZXNzYWlyZSDv v73vv70gdm90cmUgcGxhY2UmbmJzcDs6CjwvcGFyYT4KPHNjcmVlbj4KPGNvbW1hbmQ+CiMgY2hj b24gLS1yZWZlcmVuY2U9L3Zhci93d3cvaHRtbCAvdmFyL2FwYWNoZS9odG1sCjwvY29tbWFuZD4K PC9zY3JlZW4+Cgo8cGFyYT4KUG91ciBkZXMgaW5mb3JtYXRpb25zIHN1cHBs77+977+9bWVudGFp cmVzLCA8Y29tbWFuZD5jaG1vZDwvY29tbWFuZD4gZXQgPGNvbW1hbmQ+Y2hvd248L2NvbW1hbmQ+ IHV0aWxpc2VudCDvv73vv71nYWxlbWVudCBsYSBt77+977+9bWUgb3B0aW9uLCBwYXIgZXhlbXBs ZSZuYnNwOzoKPC9wYXJhPgo8c2NyZWVuPgo8Y29tbWFuZD4KIyBjaG1vZCAtLXJlZmVyZW5jZT0v dmFyL3d3dy9odG1sIC92YXIvYXBhY2hlL2h0bWwKPC9jb21tYW5kPgo8L3NjcmVlbj4KCjxwYXJh Pgpk77+977+9ZmluaXNzZXogZXhhY3RlbWVudCBsZXMgbe+/ve+/vW1lcyBwZXJtaXNzaW9ucyBk J2FjY++/ve+/vXMgcG91ciBsZXMgZGV1eCBy77+977+9cGVydG9pcmVzLgo8L3BhcmE+Cjwvc2Vj dGlvbj4KCgo8c2VjdGlvbiBpZD0ic3RyYXRlZ2llIj48dGl0bGU+ICAgIFF1ZWwgZXN0IGxlIG5v bSBkZSBjZSA8Zm9yZWlnbnBocmFzZT5zY3JpcHQ8L2ZvcmVpZ25waHJhc2U+IChjYWNo77+977+9 KSZuYnNwOz88L3RpdGxlPgo8cGFyYT4KQXUgZmlsIGRlcyBhbnMsIGonYWkg77+977+9Y3JpdCBk ZXMgY2VudGFpbmVzIGRlIDxmb3JlaWducGhyYXNlPnNjcmlwdHM8L2ZvcmVpZ25waHJhc2U+IHBv dXIgbSdhaWRlciBkYW5zIGRpdmVyc2VzIHTvv73vv71jaGVzLiBOb21icmUgZCdlbnRyZSBldXgg c29udCBlbmNvcmUgdHLvv73vv71zIHV0aWxlcyZtZGFzaDttYWlzIHBldXQt77+977+9dHJlIG1h IG3vv73vv71tb2lyZSBuJ2VzdCBwbHVzIGNlIHF1J2VsbGUg77+977+9dGFpdCBvdSBwZXV0Le+/ ve+/vXRyZSBqJ2FpIHRyb3AgZGUgY2hvc2VzIO+/ve+/vSBnYXJkZXIgZW4gdO+/ve+/vXRlLCBt YWlzIGplIG1lIHN1aXMgc291dmVudCB2dSBlbiB0cmFpbiBkZSBjaGVyY2hlciBldCBkZSBwZXN0 ZXIgcXVhbmQgamUgbmUgcG91dmFpcyBwYXMgdHJvdXZlciBsZSA8Zm9yZWlnbnBocmFzZT5zY3Jp cHQ8L2ZvcmVpZ25waHJhc2U+IGRvbnQgaidhdmFpcyBiZXNvaW4gZXQgcXVlIGplIHNhdmFpcyBh dm9pciBk77+977+9au+/ve+/vSDvv73vv71jcml0LiBUcm9wIGRlIDxmb3JlaWducGhyYXNlPnNj cmlwdHM8L2ZvcmVpZ25waHJhc2U+Jm5ic3A7IQo8L3BhcmE+Cgo8cGFyYT4KUG91ciByZW3vv73v v71kaWVyIO+/ve+/vSBjZWxhLCBqJ2FpIGNvbW1lbmPvv73vv70g77+977+9IGNvcGllciBxdWVs cXVlIGNob3NlIHF1ZSBqJ2FpIGTvv73vv71q77+977+9IGZhaXQgYWlsbGV1cnMuIFF1YW5kIGon ZW5zZWlnbmUsIGplIGRvbm5lIO+/ve+/vSBtZXMg77+977+9bO+/ve+/vXZlcyB1biBlbnNlbWJs ZSBkZSA8Zm9yZWlnbnBocmFzZT5zY3JpcHRzPC9mb3JlaWducGhyYXNlPiBxdWUgaidhaSBtaXMg ZW4gcGxhY2UgcG91ciBjaGFxdWUgY2xhc3NlJm1kYXNoOwpldCBkYW5zIGNoYWN1biBkZSBjZXMg PGZvcmVpZ25waHJhc2U+c2NyaXB0czwvZm9yZWlnbnBocmFzZT4sIGonaW5z77+977+9cmUgdW4g Y29tbWVudGFpcmUgZCdleHBsaWNhdGlvbiDvv73vv70gbGEgbGlnbmUmbmJzcDszICgxIGVzdCBw b3VyIGxlIDxmb3JlaWducGhyYXNlPnNoZWJhbmc8L2ZvcmVpZ25waHJhc2U+LCBwZW5kYW50IHF1 ZSAyIGVzdCB1biBjb21tZW50YWlyZSBmYWlzYW50IG1lbnRpb24gZGUgbCdhdXRldXIgZXQgdW5l IGVzdGFtcGlsbGUgdGVtcG9yZWxsZS4pIEonZXNzYWllIGRlIHRyb3V2ZXIgZGVzIG1vdHMtY2zv v73vv71zIHF1aSBzZXJvbnQg77+977+9dmlkZW50cyBt77+977+9bWUgc2kgamUgbmUgbWUgc291 dmllbnMgcGx1cyBkZSBjZSBxdWUgaidhaSDvv73vv71jcml0IG9yaWdpbmFsZW1lbnQuIEonYWkg YXVzc2kgYWpvdXTvv73vv70gdW4gPGZvcmVpZ25waHJhc2U+c2NyaXB0PC9mb3JlaWducGhyYXNl PiA8Zm9yZWlnbnBocmFzZT5SRUFETUU8L2ZvcmVpZ25waHJhc2U+IHF1aSBwcu+/ve+/vXNlbnRl IGxhIHRyb2lzae+/ve+/vW1lIGxpZ25lIGRlIGNoYXF1ZSBmaWNoaWVyIGRhbnMgbGUgcu+/ve+/ vXBlcnRvaXJlLiBJbCBleGlzdGUgbe+/ve+/vW1lIHVuZSBt77+977+9dGhvZGUgcG91ciBpZ25v cmVyIGRlcyBmaWNoaWVycyBldCBham91dGVyIHZvcyBwcm9wcmVzIGRlc2NyaXB0aW9ucyAoZXNz YXllciBkJ++/ve+/vXZpdGVyIGNlcyBkZXJuae+/ve+/vXJlcywgcG91ciBkZXMgcmFpc29ucyDv v73vv712aWRlbnRlcy4pCjwvcGFyYT4KPHBhcmE+CkRvbmMsIHRvdXQgY2UgcXVlIHZvdXMgZGV2 ZXogZmFpcmUgZXN0IGRlIHByZW5kcmUgbCdoYWJpdHVkZSBkZSBjb21tZW50ZXIgY2xhaXJlbWVu dCB2b3MgPGZvcmVpZ25waHJhc2U+c2NyaXB0czwvZm9yZWlnbnBocmFzZT4gbm90YW1tZW50IO+/ ve+/vSBsYSB0cm9pc2nvv73vv71tZSBsaWduZS4gVW5lIGZvaXMgY2VjaSBmYWl0LCBjZSBwZXRp dCA8Zm9yZWlnbnBocmFzZT5zY3JpcHQ8L2ZvcmVpZ25waHJhc2U+IHZvdXMgcGVybWV0dHJhIGQn 77+977+9Y29ub21pc2VyIGJlYXVjb3VwIGRlIHRlbXBzIGV0IGRlIGZydXN0cmF0aW9uLiAKPC9w YXJhPgoKPHByb2dyYW1saXN0aW5nPgojIS9iaW4vc2gKIyBDcu+/ve+/vWUgcGFyIEJlbiBPa29w bmlrIGxlIGRpbWFuY2hlIDEwIETvv73vv71jZW1icmUKIyBFeO+/ve+/vWN1dGV6IGNlIHNjcmlw dCBwb3VyIGFmZmljaGVyIGxlcyBkZXNjcmlwdGlvbnMgZGUgdG91cyBsZXMgZmljaGllcnMgZGFu cyBjZSBy77+977+9cGVydG9pcmUKIApyZWplY3Q9J2Eub3V0IHJlZ2V4LjcgYWNjZXNzLmxvZycK cHJpbnRmICIlLTI1cyVzXG4iICJyZWdleC43IiAgICAiIyBIZW5yeSBTcGVuY2VyJ3MgcmVndWxh ciBleHByZXNzaW9ucyIKcHJpbnRmICIlLTI1cyVzXG4iICJhY2Nlc3MubG9nIiAiIyBUeXBpY2Fs IEFwYWNoZSBsb2cgZmlsZSIKIApmb3IgbiBpbiAqCmRvCiAgICBbIC1mICIkbiIgLWEgLXogImBl Y2hvICRyZWplY3R8Z3JlcCBcIlwmIzYwOyRuXD5cImAiIF0gfHwgY29udGludWUKICAgIHByaW50 ZiAiJS0yNXMlc1xuIiAiJG4iICJgL2Jpbi9zZWQgLW4gJzNwJyBcIiRuXCJgIgpkb25lCjwvcHJv Z3JhbWxpc3Rpbmc+Cgo8YmxvY2txdW90ZT4KPHBhcmE+CkJlbiBlc3QgbGUgcu+/ve+/vWRhY3Rl dXIgZW4gY2hlZiBkZSBsYSA8dHJhZGVtYXJrIGNsYXNzPSJjb3B5cmlnaHQiPjx1bGluayB1cmw9 Imh0dHA6Ly9saW51eGdhemV0dGUubmV0Ij5MaW51eCBHYXpldHRlPC91bGluaz48L3RyYWRlbWFy az4gZXQgaWwgZXN0IG1lbWJyZSBkZSBsJyZsYXF1bzsmbmJzcDs8dHJhZGVtYXJrIGNsYXNzPSJj b3B5cmlnaHQiPkFuc3dlciBHYW5nPC90cmFkZW1hcms+Jm5ic3A7JnJhcXVvOy4KPC9wYXJhPgoK PHBhcmE+CkJlbiBlc3Qgbu+/ve+/vSDvv73vv70gTW9zY291IGVuIFJ1c3NpZSBlbiAxOTYyLiBJ bCBhIGNvbW1lbmPvv73vv70g77+977+9IHMnaW5077+977+9cmVzc2VyIO+/ve+/vSBsJ++/ve+/ vWxlY3RyaWNpdO+/ve+/vSBk77+977+9cyBsJ++/ve+/vWdlIGRlIDYgYW5zIGVuIGVuZm9u77+9 77+9YW50IHVuZSBmb3VyY2hldHRlIGRhbnMgdW5lIHByaXNlIGV0IGTvv73vv71jbGVuY2hhbnQg YWluc2kgdW4gaW5jZW5kaWUsIGRlcHVpcyBpbCBuJ2EgamFtYWlzIGNlc3Pvv73vv70gZGUgcydp bnTvv73vv71yZXNzZXIg77+977+9IGxhIHRlY2hub2xvZ2llLiBJbCB0cmF2YWlsbGUgYXZlYyBs ZXMgb3JkaW5hdGV1cnMgZGVwdWlzIGxlcyBUZW1wcyBBbmNpZW5zIG/vv73vv70gbCdvbiBkZXZh aXQgc291ZGVyIHNvaS1t77+977+9bWUgZGVzIGNvbXBvc2FudHMgc3VyIGRlcyBjYXJ0ZXMg77+9 77+9IGNpcmN1aXRzIGltcHJpbe+/ve+/vXMgZXQgb++/ve+/vSBsZXMgcHJvZ3JhbW1lcyBkZXZh aWVudCB0ZW5pciBkYW5zIDQmbmJzcDtrbyBkZSBt77+977+9bW9pcmUuIElsIHNlcmFpdCBoZXVy ZXV4IGRlIHBheWVyIHRvdXQgcHN5Y2hvbG9ndWUgY2FwYWJsZSBkZSBsZSBnde+/ve+/vXJpciBk ZXMgY2F1Y2hlbWFycyBy77+977+9Y3VycmVudHMgcXUnaWwgYSBnYXJk77+977+9cyBkZSBjZXR0 ZSDvv73vv71wb3F1ZS4KPC9wYXJhPgoKPHBhcmE+ClNlcyBleHDvv73vv71yaWVuY2VzIHN1aXZh bnRlcyBjb21wcmVubmVudCBsYSBjcu+/ve+/vWF0aW9uIGRlIHByb2dyYW1tZXMgZGFucyBwcmF0 aXF1ZW1lbnQgdW5lIGRvdXphaW5lIGRlIGxhbmdhZ2VzLCBsYSBtYWludGVuYW5jZSBkZSBy77+9 77+9c2VhdXggZXQgZGUgYmFzZXMgZGUgZG9ubu+/ve+/vWVzIHBlbmRhbnQgbCdhcHByb2NoZSBk J3VuIG91cmFnYW4gZXQgbCfvv73vv71jcml0dXJlIGQnYXJ0aWNsZXMgcG91ciBkZXMgcHVibGlj YXRpb25zIGFsbGFudCBkZXMgbWFnYXppbmVzIGRlIHZvaWxlIGF1eCBqb3VybmF1eCB0ZWNobm9s b2dpcXVlcy4gQXBy77+977+9cyB1bmUgY3JvaXNp77+977+9cmUgZGUgNyZuYnNwO2FucyBkYW5z IGwnQXRsYW50aXF1ZSBldCBsZXMgQ2FyYe+/ve+/vWJlcyBhaW5zaSBxdWUgZGVzIHBhc3NhZ2Vz IHN1ciBsYSBj77+977+9dGUgRXN0IGRlcyDvv73vv710YXRzLVVuaXMsIGlsIGEgZO+/ve+/vXNv cm1haXMgamV077+977+9IGwnYW5jcmUg77+977+9IFN0LUF1Z3VzdGluZSwgZW4gRmxvcmlkZS4g SW5zdHJ1Y3RldXIgdGVjaG5pcXVlIGNoZXogPHRyYWRlbWFyayBjbGFzcz0iY29weXJpZ2h0Ij5T dW4gTWljcm9zeXN0ZW1zPC90cmFkZW1hcms+LCBpbCB0cmF2YWlsbGUg77+977+9Z2FsZW1lbnQg 77+977+9IHRpdHJlIHByaXbvv73vv70gY29tbWUgY29uc3VsdGFudCA8Zm9yZWlnbnBocmFzZT5v cGVuIHNvdXJjZTwvZm9yZWlnbnBocmFzZT4gZXQgZO+/ve+/vXZlbG9wcGV1ciB3ZWIuIFNlcyBw YXNzZS10ZW1wcyBhY3R1ZWxzIHNvbnQgbm90YW1tZW50IGwnYXZpYXRpb24sIGxlIHlvZ2EsIGxl cyBhcnRzIG1hcnRpYXV4LCBsYSBtb3RvLCBsJ++/ve+/vWNyaXR1cmUgZXQgbCdoaXN0b2lyZSBy b21haW5lLiBTb24gPHRyYWRlbWFyayBjbGFzcz0iY29weXJpZ2h0Ij5QYWxtIFBpbG90PC90cmFk ZW1hcms+IGVzdCB0cnVmZu+/ve+/vSBkJ2FsYXJtZXMgZG9udCBsYSBwbHVwYXJ0IGNvbnRpZW5u ZW50IGRlcyBwb2ludHMgZCdleGNsYW1hdGlvbi4KPC9wYXJhPgo8L2Jsb2NrcXVvdGU+CgoKPC9z ZWN0aW9uPgoKPGNvbG9waG9uIGlkPSJhZGFwdCI+PHRpdGxlPkFkYXB0YXRpb24gZnJhbu+/ve+/ vWFpc2UgZGUgbGEgR2F6ZXR0ZSZuYnNwO0xpbnV4PC90aXRsZT4KCjxwYXJhPgpMJ2FkYXB0YXRp b24gZnJhbu+/ve+/vWFpc2UgZGUgY2UgZG9jdW1lbnQgYSDvv73vv71077+977+9IHLvv73vv71h bGlz77+977+9ZSBkYW5zIGxlIGNhZHJlIGR1IDxjaXRldGl0bGU+UHJvamV0IGRlIHRyYWR1Y3Rp b24gZGUgbGEgR2F6ZXR0ZSZuYnNwO0xpbnV4PC9jaXRldGl0bGU+Lgo8L3BhcmE+Cgo8cGFyYT4K Vm91cyBwb3VycmV6IGxpcmUgZCdhdXRyZXMgYXJ0aWNsZXMgdHJhZHVpdHMgZXQgZW4gYXBwcmVu ZHJlIHBsdXMgc3VyIGNlIHByb2pldCBlbiB2aXNpdGFudCBub3RyZSBzaXRlJm5ic3A7OiA8dWxp bmsgdXJsPSJodHRwOi8vd2lraS50cmFkdWMub3JnL0dhemV0dGVfTGludXgiLz4uCjwvcGFyYT4K CjxwYXJhPgpTaSB2b3VzIHNvdWhhaXRleiBhcHBvcnRlciB2b3RyZSBjb250cmlidXRpb24sIG4n aO+/ve+/vXNpdGV6IHBhcyDvv73vv70gbm91cyByZWpvaW5kcmUsIG5vdXMgc2Vyb25zIGhldXJl dXggZGUgdm91cyBhY2N1ZWlsbGlyLgo8L3BhcmE+CjwvY29sb3Bob24+Cgo8L2FydGljbGU+Cg== --===============6246833100734054150==-- From jdd@dodin.org Tue Mar 3 12:21:44 2009 From: jdd To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 12:20:56 +0100 Message-ID: <49AD1298.9070103@dodin.org> In-Reply-To: <49AD09B4.2000507@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8723324377377254340==" --===============8723324377377254340== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit deny a écrit : > je fais afficher en docbook et ensuite je récupère le fichier généré > et attention les yeux,le voici le voila plusieurs choses, ici: 1) à quoi bon changer un fichier qui passe les scripts sans problème? 2) l'original (sur le wiki) était-il organisé proprement? 3) serait-t'il possible d'améliorer le script py qui fait la conversion? Ce ne sont pas des questions en l'air. Je suis le coordinateur du LDP et les essais que nous avons fait sont limités. S'il y a un vrai problème, ça m'intéresse de savoir comment le corriger. jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 --===============8723324377377254340==-- From deny@monaco.net Tue Mar 3 12:31:04 2009 From: deny To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 12:30:53 +0100 Message-ID: <49AD14ED.5060706@monaco.net> In-Reply-To: <49AD1298.9070103@dodin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3026205526506300863==" --===============3026205526506300863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Le 03/03/2009 12:20 PM, en cette journée d'hiver *jdd* a écrit fort à propos : > deny a écrit : > >> je fais afficher en docbook et ensuite je récupère le fichier généré >> et attention les yeux,le voici le voila > > plusieurs choses, ici: > > 1) à quoi bon changer un fichier qui passe les scripts sans problème? je viens de prendre la peine de vous l'expliquer en vous envoyant le fichier généré et le résultat que je dois obtenir pour l'afficher sur le site . > 2) l'original (sur le wiki) était-il organisé proprement? j'en sais rien , mais si un nouveau traducteur en vient à générer un fichier aussi mal formaté , c'est que le wiki pose un problème, ce genre d'outil étant chargé en principe de permettre l'écriture sans se soucier du formatage ........ > 3) serait-t'il possible d'améliorer le script py qui fait la conversion? je ne programme pas py , cela me passe largement au-dessus > > Ce ne sont pas des questions en l'air. Je suis le coordinateur du LDP > et les essais que nous avons fait sont limités. S'il y a un vrai > problème, ça m'intéresse de savoir comment le corriger. Le problème pour moi est résolu, je n'accepterai pas à l'avenir des fichiers formatés tels que le torchon que je viens de recevoir Et si certains s'en émeuvent, qu'ils prennent ma place , je la rend volontiers Déjà 4h que j'essaie d'avoir mes identifiants pour me connecter au wiki, pas un seul retour de la part de jean-philippe Guérard Voila ce que je pense, on veut bien avoir un bon zig (pour ne pas dire autre chose) qui coordonne et prend un peu de la peine, mais quand il faut dépanner ou mettre les mains dans le cambouis, il n'y a plus personne ........... Alors ce que je pense , c'est que si ca continue en l'état, pas de réponses aux questions posées, je vais me désinscrire tranquillement et sans m'en traumatiser pour autant , bien gentil d'avertir avant Salut --===============3026205526506300863==-- From jdd@dodin.org Tue Mar 3 13:23:15 2009 From: jdd To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 13:22:27 +0100 Message-ID: <49AD2103.40709@dodin.org> In-Reply-To: <49AD14ED.5060706@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8672561002222190644==" --===============8672561002222190644== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit deny a écrit : >> 1) à quoi bon changer un fichier qui passe les scripts sans problème? > > je viens de prendre la peine de vous l'expliquer en vous envoyant le > fichier généré et le résultat que je dois obtenir pour l'afficher sur le > site . c'est ca que je ne comprends pas. Au LDP, tout fichier source est mouliné par des scripts qui se chargent des conversions pour le site web. Les tests que nous avons fait Exemple de résultat: http://wiki.tldp.org/Partition-Rescue avec ces instructions: http://wiki.tldp.org/Converting-a-HOWTO#ConvertingfromWikitoDocbookxml semblent sans problème >> 2) l'original (sur le wiki) était-il organisé proprement? > > j'en sais rien , mais si un nouveau traducteur en vient à générer un > fichier aussi mal formaté , c'est que le wiki pose un problème, ce genre > d'outil étant chargé en principe de permettre l'écriture sans se soucier > du formatage ........ c'est un de mes soucis. J'ai commencé par écrire le docbook à la main (vi) et la structure est assez contraignante. Si le wiki est écrit n'importe comment (au point de vue organisation du document, je ne parle pas du sens), la traduction doit être problématique. Pour l'instant c'est moi qui fais les soumissions, après controle rapide, mais comme la plupart de nos textes sont d'anciens HOWTO, leur structure est correcte au départ. Pour une traduction, ca devrait être pareil. > Le problème pour moi est résolu, je n'accepterai pas à l'avenir des > fichiers formatés tels que le torchon que je viens de recevoir > Et si certains s'en émeuvent, qu'ils prennent ma place , je la rend > volontiers pourquoi se fâcher? il vaut mieux d'abord chercher à comprendre ce qui ne va pas. Personnellement, je n'ai jamais envisagé que le docbook du wiki soit ensuite re-édité à la main. j'ai déjà vu des codes passés par un optimiseur devenus illisibles à l'homme :-( > > Déjà 4h que j'essaie d'avoir mes identifiants pour me connecter au wiki, > pas un seul retour de la part de jean-philippe Guérard sur celui du LDP, l'accès est libre http://wiki.tldp.org/FrontPage On peut donc parfaitement y ouvrir une rubrique traduction si ca intéresse quelqu'un (mais ce serait domage de faire concurrence à un système déjà en place sans raison majeure) > > Voila ce que je pense, on veut bien avoir un bon zig (pour ne pas dire > autre chose) qui coordonne et prend un peu de la peine, mais quand il > faut dépanner ou mettre les mains dans le cambouis, il n'y a plus > personne ........... je sais ce que c'est :-) jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 --===============8672561002222190644==-- From jean-philippe.guerard@tigreraye.org Tue Mar 3 13:28:16 2009 From: Jean-Philippe =?utf-8?q?Gu=C3=A9rard?= To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 12:28:03 +0000 Message-ID: <026558eea560c87f1af46b5d05e09e3d.squirrel@tigreraye.org> In-Reply-To: <49AD14ED.5060706@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1471984946436975779==" --===============1471984946436975779== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> deny a =C3=A9crit : >> >>> je fais afficher en docbook et ensuite je r=C3=A9cup=C3=A8re le fichier g= =C3=A9n=C3=A9r=C3=A9 >>> et attention les yeux,le voici le voila Je regarde ce soir ce qui ne vas pas et ce que l'on peut faire. > D=C3=A9j=C3=A0 4h que j'essaie d'avoir mes identifiants pour me connecter a= u wiki, > pas un seul retour de la part de jean-philippe Gu=C3=A9rard Merci. Je suis au travail pour l'instant. Le plus simple est d'utiliser la fonction =C2=AB=C2=A0Mot de passe oubli=C3=A9=C2=A0?=C2=A0=C2=BB. Si =C3=A7a = ne marche pas, je regarderai ce soir. =C3=80+ --=20 Jean-Philippe Gu=C3=A9rard http://tigreraye.org --===============1471984946436975779==-- From deny@monaco.net Tue Mar 3 13:41:44 2009 From: deny To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 13:41:31 +0100 Message-ID: <49AD257B.60302@monaco.net> In-Reply-To: <49AD2103.40709@dodin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5298462414378732256==" --===============5298462414378732256== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit L > > c'est ca que je ne comprends pas. Au LDP, tout fichier source est > mouliné par des scripts qui se chargent des conversions pour le site > web. Les tests que nous avons fait > > Exemple de résultat: > http://wiki.tldp.org/Partition-Rescue > > avec ces instructions: > http://wiki.tldp.org/Converting-a-HOWTO#ConvertingfromWikitoDocbookxml > > semblent sans problème eh bien dans mon cas, si vous prenez peine de convertir le texte généré au format html, ce que l'on fait avec la commande : xsltproc /usr/share/apps/ksgmltools2/docbook/xsl/html/docbook.xsl /home/traduc/mon_document.xml > document.html on obtient ca http://www.linux-pour-lesnuls.com/lg149-C.html et ce n'est effectivement pas présentable il me faut obtenir ca par exemple : http://ftp.traduc.org/doc-vf/gazette-linux/html/2009/160/lg160-A.html donc tout ca je sais le faire, mais ce me prend 2h pour tout corriger ce que je n'ai pas besoin de faire avec un fichier xml que le traducteur a fait de lui-même avec le modèle présenté dans la procédure . En passant par le wiki, ca merdoie > >> Le problème pour moi est résolu, je n'accepterai pas à l'avenir des >> fichiers formatés tels que le torchon que je viens de recevoir >> Et si certains s'en émeuvent, qu'ils prennent ma place , je la rend >> volontiers > > pourquoi se fâcher? il vaut mieux d'abord chercher à comprendre ce qui > ne va pas. Personnellement, je n'ai jamais envisagé que le docbook du > wiki soit ensuite re-édité à la main. j'ai déjà vu des codes passés > par un optimiseur devenus illisibles à l'homme :-( moi non plus , mais comme c'est le premier fichier que je recois en provenance du wiki, il faut bien que je proteste et que je le fasse savoir, car personne ne fera la relecture à ma place. Et la-dessus je me sens un peu seul, je n'ai pas même mes identifiants de connexion pour pouvoir accéder au wiki et supprimer dans la procédure la référence au wiki, histoire de limiter les dégats pour de futurs traducteurs > >> Déjà 4h que j'essaie d'avoir mes identifiants pour me connecter au wiki, >> pas un seul retour de la part de jean-philippe Guérard > > sur celui du LDP, l'accès est libre http://wiki.tldp.org/FrontPage ben la , il faut se connecter pour modifier les pages > > On peut donc parfaitement y ouvrir une rubrique traduction si ca > intéresse quelqu'un (mais ce serait domage de faire concurrence à un > système déjà en place sans raison majeure) Non, pas question , le responsable se bouge ou je me casse, c'est pas négociable, et ca fait déjà trop longtemps que je parlemente De toute façon , cette liste est morte, a part quelques articles que je poste, par ci, par là, personne n'intervient, tu cries dans le désert, c'est un hall de gare vide, la nuit des morts-vivants, faudrait les pincer pour en reveiller quelques-uns, on dirait le sénat à l'heure de pointe ! >> Voila ce que je pense, on veut bien avoir un bon zig (pour ne pas dire >> autre chose) qui coordonne et prend un peu de la peine, mais quand il >> faut dépanner ou mettre les mains dans le cambouis, il n'y a plus >> personne ........... > > je sais ce que c'est :-) Eh bien, tu as bien de la patience, moi je n'aime pas les monologues D'ailleurs assez discuté, autant joindre le geste à la parole Salut les morts-vivants et bonne digestion pour ceux qui restent . Unsuscribe --===============5298462414378732256==-- From jdd@dodin.org Tue Mar 3 14:01:47 2009 From: jdd To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 14:00:58 +0100 Message-ID: <49AD2A0A.6080509@dodin.org> In-Reply-To: <49AD257B.60302@monaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1577706236310531345==" --===============1577706236310531345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit deny a écrit : > http://www.linux-pour-lesnuls.com/lg149-C.html > et ce n'est effectivement pas présentable si je compare à ce que vous montrez, je vois essentiellement * il y a une ligne par modification du source. C'est ajouté par le convertisseur. Il m'a été dit par les anciens du LDP qu'il vallait mieux conserver toutes ces lignes, il faut simplement que celui qui fait les modifs renseigne la ligne de commentaire du wiki lors des éditions. Ca se discute (le maintien), en tout état de cause ca doit être très facile à modifier sur le script de génération, * il manque sur le wiki la macro <>, ce qui veut dire normalement que l'auteur n'a pas voulu de table des matières (ou qu'il ne sait pas utiliser le wiki) * le reste manque dans le source parce qu'il n'y a pas été mis > En passant par le wiki, ca merdoie en passant par le wiki il ne faut pas mettre le nez dans le code - ou alors il ne faut pas passer par le wiki (c'est aussi une solution, que vous avez le droit de préférer) > moi non plus , mais comme c'est le premier fichier que je recois en > provenance du wiki, il faut bien que je proteste et que je le fasse > savoir, car personne ne fera la relecture à ma place. je n'ai toujours pas compris pourquoi vous voulez modifier le code à la main au lieu de modifier le source. Quel est l'usage ultérieur du xml? > c'est un hall de gare vide, la nuit des morts-vivants, faudrait les > pincer pour en reveiller quelques-uns, on dirait le sénat à l'heure de > pointe ! c'est un peu pour changer ce genre de chose que j'ai pris la direction du LDP :-) > Unsuscribe ca, ca doit pas marcher comme ca :-) jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 --===============1577706236310531345==-- From jdd@dodin.org Tue Mar 3 14:41:16 2009 From: jdd To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 14:40:26 +0100 Message-ID: <49AD334A.6020307@dodin.org> In-Reply-To: <49AD2A0A.6080509@dodin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4039988869411320106==" --===============4039988869411320106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit jdd a écrit : > * il manque sur le wiki la macro <> erreur de ma part. Il n'y tout simplement pas de titres (seulement du texte en gras) donc le défaut vient du source et du traducteur, pas du script de conversion, la même erreur était probable dans le xml jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 --===============4039988869411320106==-- From sakatour@yahoo.fr Tue Mar 3 15:36:16 2009 From: kamal sawal TOURE To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 14:36:01 +0000 Message-ID: <761396.63698.qm@web26104.mail.ukl.yahoo.com> In-Reply-To: <49AD334A.6020307@dodin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6343101536551881295==" --===============6343101536551881295== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bonjour, Je pense que l'erreur vient en effet du traducteur, en l'occurrence moi.=20 Apr=C3=A8s avoir cr=C3=A9=C3=A9=C2=A0 le brouillon conform=C3=A9ment =C3=A0 l= a proc=C3=A9dure , je me suis retrouv=C3=A9 avec une page vierge et je ne sav= ais pas comment import=C3=A9 l'article original avec ses balises. J'ai donc j= uste fait un copier-coller et essay=C3=A9 de mettre les balises =C3=A0 la mai= n en me basant sur les indications en bas de la page. Je suis d=C3=A9sol=C3=A9 et surpris d'avoir cr=C3=A9=C3=A9 autant d'=C3=A9mot= ions. Renvoyez moi le fichier source xml et dites moi avec quel =C3=A9diteur = (sous windows) je peux l'editer sans toucher aux balises. La proc=C3=A9dure dit aussi "ou bien si vous souhaitez traduire sans vous embarrasser des probl=C3=A8mes = de formatage, en simple fichier texte ou html." Ca aussi je peux faire: envoyer sous forme d'un fichier txt. Dans ce cas, ce = sera au correcteur de mettre les balises? Y a t'il aussi la possibilit=C3=A9 d'envoyer l'article original au format txt= ? (La proc=C3=A9dure ne mentionne pas sous quel format l'article est envoy=C3= =A9) D=C3=A9sol=C3=A9 avec mes questions d=C3=A9biles de d=C3=A9butant, mais je d= =C3=A9bute avec le format docbook... Kamal Sawal TOURE --- En date de=C2=A0: Mar 3.3.09, jdd a =C3=A9crit=C2=A0: De: jdd Objet: Re: [Traduc] probl=C3=A8me =C3=80: "trad >> "traduc.org"" Date: Mardi 3 Mars 2009, 14h40 jdd a =C3=A9crit : > * il manque sur le wiki la macro <> erreur de ma part. Il n'y tout simplement pas de titres (seulement du texte en gras) donc le d=C3=A9faut vient du source et du traducteur, pas du script de conversion, la m=C3=AAme erreur =C3=A9tait probable dans le xml jdd --=20 http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=3Dt-eic8MSSfM http://www.facebook.com/profile.php?id=3D1412160445 _______________________________________________ Liste de discussion Traduc Traduc(a)traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pi=C3=A8ces-jointes doivent attendre l'approbation du mod=C3=A9rateur.] =20 --===============6343101536551881295== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIiA+PHRyPjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9ImZvbnQ6IGluaGVyaXQ7Ij5Cb25qb3VyLDxicj48YnI+SmUg cGVuc2UgcXVlIGwnZXJyZXVyIHZpZW50IGVuIGVmZmV0IGR1IHRyYWR1Y3RldXIsIGVuIGwnb2Nj dXJyZW5jZSBtb2kuIDxicj5BcHLocyBhdm9pciBjcunpJm5ic3A7IGxlIGJyb3VpbGxvbiBjb25m b3Jt6W1lbnQg4CBsYSA8YSBocmVmPSJodHRwOi8vd3d3LnRyYWR1Yy5vcmcvR2F6ZXR0ZV9MaW51 eC9Qcm9jJUMzJUE5ZHVyZSI+cHJvY+lkdXJlIDwvYT4sIGplIG1lIHN1aXMgcmV0cm91dukgYXZl YyB1bmUgcGFnZSB2aWVyZ2UgZXQgamUgbmUgc2F2YWlzIHBhcyBjb21tZW50IGltcG9ydOkgbCdh cnRpY2xlIG9yaWdpbmFsIGF2ZWMgc2VzIGJhbGlzZXMuIEonYWkgZG9uYyBqdXN0ZSBmYWl0IHVu IGNvcGllci1jb2xsZXIgZXQgZXNzYXnpIGRlIG1ldHRyZSBsZXMgYmFsaXNlcyDgIGxhIG1haW4g ZW4gbWUgYmFzYW50IHN1ciBsZXMgaW5kaWNhdGlvbnMgZW4gYmFzIGRlIGxhIHBhZ2UuPGJyPjxi cj48YnI+SmUgc3VpcyBk6XNvbOkgZXQgc3VycHJpcyBkJ2F2b2lyIGNy6ekgYXV0YW50IGQn6W1v dGlvbnMuIFJlbnZveWV6IG1vaSBsZSBmaWNoaWVyIHNvdXJjZSB4bWwgZXQgZGl0ZXMgbW9pIGF2 ZWMgcXVlbCDpZGl0ZXVyIChzb3VzIHdpbmRvd3MpIGplIHBldXggbCdlZGl0ZXIgc2FucyB0b3Vj aGVyIGF1eCBiYWxpc2VzLjxicj48YnI+TGEgcHJvY+lkdXJlIGRpdCBhdXNzaTxicj48YnI+PHNw YW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPiJvdSBiaWVuIHNpIHZvdXMgc291aGFpdGV6 IHRyYWR1aXJlIHNhbnMgdm91cyBlbWJhcnJhc3NlciBkZXMgcHJvYmzobWVzIGRlIGZvcm1hdGFn ZSwgZW4gc2ltcGxlIGZpY2hpZXIgdGV4dGUgb3UKIGh0bWwuIjwvc3Bhbj48YnI+PGJyPkNhIGF1 c3NpIGplIHBldXggZmFpcmU6IGVudm95ZXIgc291cyBmb3JtZSBkJ3VuIGZpY2hpZXIgdHh0LiBE YW5zIGNlIGNhcywgY2Ugc2VyYSBhdSBjb3JyZWN0ZXVyIGRlIG1ldHRyZSBsZXMgYmFsaXNlcz88 YnI+PGJyPlkgYSB0J2lsIGF1c3NpIGxhIHBvc3NpYmlsaXTpIGQnZW52b3llciBsJ2FydGljbGUg b3JpZ2luYWwgYXUgZm9ybWF0IHR4dD8gKExhIHByb2PpZHVyZSBuZSBtZW50aW9ubmUgcGFzIHNv dXMgcXVlbCBmb3JtYXQgbCdhcnRpY2xlIGVzdCBlbnZveekpPGJyPjxicj5E6XNvbOkgYXZlYyBt ZXMgcXVlc3Rpb25zIGTpYmlsZXMgZGUgZOlidXRhbnQsIG1haXMgamUgZOlidXRlIGF2ZWMgbGUg Zm9ybWF0IGRvY2Jvb2suLi48YnI+PGJyPjxicj48ZGl2PkthbWFsIFNhd2FsIFRPVVJFPC9kaXY+ PGJyPjxicj4tLS0gRW4gZGF0ZSBkZSZuYnNwOzogPGI+TWFyIDMuMy4wOSwgamRkIDxpPiZsdDtq ZGRAZG9kaW4ub3JnJmd0OzwvaT48L2I+IGEg6WNyaXQmbmJzcDs6PGJyPjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXItbGVmdDogMnB4IHNvbGlkIHJnYigxNiwgMTYsIDI1NSk7IG1hcmdpbi1sZWZ0 OiA1cHg7IHBhZGRpbmctbGVmdDogNXB4OyI+RGU6IGpkZCAmbHQ7amRkQGRvZGluLm9yZyZndDs8 YnI+T2JqZXQ6IFJlOiBbVHJhZHVjXSBwcm9ibOhtZTxicj7AOiAidHJhZCAmZ3Q7Jmd0OyAidHJh ZHVjLm9yZyIiICZsdDt0cmFkdWNAdHJhZHVjLm9yZyZndDs8YnI+RGF0ZTogTWFyZGkgMyBNYXJz IDIwMDksIDE0aDQwPGJyPjxicj48cHJlPmpkZCBhIOljcml0IDo8YnI+PGJyPiZndDsgKiBpbCBt YW5xdWUgc3VyIGxlIHdpa2kgbGEgbWFjcm8gJmx0OyZsdDtUYWJsZU9mQ29udGVudHMmZ3Q7Jmd0 Ozxicj48YnI+ZXJyZXVyIGRlIG1hIHBhcnQuIElsIG4neSB0b3V0IHNpbXBsZW1lbnQgcGFzIGRl IHRpdHJlcwogKHNldWxlbWVudCBkdTxicj50ZXh0ZSBlbiBncmFzKTxicj48YnI+ZG9uYyBsZSBk 6WZhdXQgdmllbnQgZHUgc291cmNlIGV0IGR1IHRyYWR1Y3RldXIsIHBhcyBkdSBzY3JpcHQgZGU8 YnI+Y29udmVyc2lvbiwgbGEgbeptZSBlcnJldXIg6XRhaXQgcHJvYmFibGUgZGFucyBsZSB4bWw8 YnI+PGJyPmpkZDxicj48YnI+LS0gPGJyPmh0dHA6Ly93d3cuZG9kaW4ubmV0PGJyPmh0dHA6Ly92 YWxlcmllLmRvZGluLm9yZzxicj5odHRwOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9dC1laWM4 TVNTZk08YnI+aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcHJvZmlsZS5waHA/aWQ9MTQxMjE2MDQ0 NTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+TGlzdGUgZGUgZGlzY3Vzc2lvbiBUcmFkdWM8YnI+VHJhZHVjQHRyYWR1Yy5vcmc8YnI+aHR0 cDovL3d3dy50cmFkdWMub3JnL21haWxtYW4vbGlzdGluZm8vdHJhZHVjPGJyPlsvIVwgTGVzIHBp 6GNlcy1qb2ludGVzIGRvaXZlbnQgYXR0ZW5kcmUgbCdhcHByb2JhdGlvbiBkdTxicj5tb2TpcmF0 ZXVyLl08YnI+PC9wcmU+PC9ibG9ja3F1b3RlPjwvdGQ+PC90cj48L3RhYmxlPjxicj4KCgoKICAg ICAg --===============6343101536551881295==-- From sakatour@yahoo.fr Tue Mar 3 19:19:15 2009 From: kamal sawal TOURE To: traduc@traduc.org Subject: Re: [Traduc] =?utf-8?q?probl=C3=A8me?= Date: Tue, 03 Mar 2009 18:18:59 +0000 Message-ID: <781546.36488.qm@web26104.mail.ukl.yahoo.com> In-Reply-To: <49AD334A.6020307@dodin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9164335090573668990==" --===============9164335090573668990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bonjour, Je pense que l'erreur vient en effet du traducteur, en l'occurrence moi.=20 Apr=C3=A8s avoir cr=C3=A9=C3=A9=C2=A0 le brouillon conform=C3=A9ment =C3=A0 l= a proc=C3=A9dure , je me suis retrouv=C3=A9 avec une page vierge et je ne savais pas comment import=C3=A9 l'article original avec ses balises. J'ai donc juste fait un copier-coller et essay=C3=A9 de mettre les balises =C3=A0 la main en me basant sur les indications en bas de la page. Je suis d=C3=A9sol=C3=A9 et surpris d'avoir cr=C3=A9=C3=A9 autant d'=C3=A9motions. Renvoyez moi le fichie= r source xml et dites moi avec quel =C3=A9diteur (sous windows) je peux l'editer sans toucher aux balises. La proc=C3=A9dure dit aussi "ou bien si vous souhaitez traduire sans vous embarrasser des probl=C3=A8mes = de formatage, en simple fichier texte ou html." Ca aussi je peux faire: envoyer sous forme d'un fichier txt. Dans ce cas, ce = sera au correcteur de mettre les balises? Y a t'il aussi la possibilit=C3=A9 d'envoyer l'article original au format txt? (La proc=C3=A9dure ne mentionne pas sous quel format l'article est envoy=C3= =A9) D=C3=A9sol=C3=A9 avec mes questions d=C3=A9biles de d=C3=A9butant, mais je d= =C3=A9bute avec le format docbook... Kamal Sawal TOURE --- En date de=C2=A0: Mar 3.3.09, jdd a =C3=A9crit=C2=A0: De: jdd Objet: Re: [Traduc] probl=C3=A8me =C3=80: "trad >> "traduc.org"" Date: Mardi 3 Mars 2009, 14h40 jdd a =C3=A9crit : > * il manque sur le wiki la macro <> erreur de ma part. Il n'y tout simplement pas de titres (seulement du texte en gras) donc le d=C3=A9faut vient du source et du traducteur, pas du script de conversion, la m=C3=AAme erreur =C3=A9tait probable dans le xml jdd --=20 http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=3Dt-eic8MSSfM http://www.facebook.com/profile.php?id=3D1412160445 _______________________________________________ Liste de discussion Traduc Traduc(a)traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pi=C3=A8ces-jointes doivent attendre l'approbation du mod=C3=A9rateur.] =20 --===============9164335090573668990== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIiA+PHRyPjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9ImZvbnQ6IGluaGVyaXQ7Ij48YnI+Qm9uam91ciw8YnI+PGJy PkplIHBlbnNlIHF1ZSBsJ2VycmV1ciB2aWVudCBlbiBlZmZldCBkdSB0cmFkdWN0ZXVyLCBlbiBs J29jY3VycmVuY2UgbW9pLiA8YnI+QXBy6HMgYXZvaXIgY3Lp6SZuYnNwOyBsZSBicm91aWxsb24g Y29uZm9ybeltZW50IOAgbGEgPGEgcmVsPSJub2ZvbGxvdyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9 Imh0dHA6Ly93d3cudHJhZHVjLm9yZy9HYXpldHRlX0xpbnV4L1Byb2MlQzMlQTlkdXJlIj5wcm9j 6WR1cmUgPC9hPiwKamUgbWUgc3VpcyByZXRyb3V26SBhdmVjIHVuZSBwYWdlIHZpZXJnZSBldCBq ZSBuZSBzYXZhaXMgcGFzIGNvbW1lbnQKaW1wb3J06SBsJ2FydGljbGUgb3JpZ2luYWwgYXZlYyBz ZXMgYmFsaXNlcy4gSidhaSBkb25jIGp1c3RlIGZhaXQgdW4KY29waWVyLWNvbGxlciBldCBlc3Nh eekgZGUgbWV0dHJlIGxlcyBiYWxpc2VzIOAgbGEgbWFpbiBlbiBtZSBiYXNhbnQKc3VyIGxlcyBp bmRpY2F0aW9ucyBlbiBiYXMgZGUgbGEgcGFnZS48YnI+PGJyPjxicj5KZSBzdWlzIGTpc29s6SBl dApzdXJwcmlzIGQnYXZvaXIgY3Lp6SBhdXRhbnQgZCfpbW90aW9ucy4gUmVudm95ZXogbW9pIGxl IGZpY2hpZXIgc291cmNlCnhtbCBldCBkaXRlcyBtb2kgYXZlYyBxdWVsIOlkaXRldXIgKHNvdXMg d2luZG93cykgamUgcGV1eCBsJ2VkaXRlciBzYW5zCnRvdWNoZXIgYXV4IGJhbGlzZXMuPGJyPjxi cj5MYSBwcm9j6WR1cmUgZGl0IGF1c3NpPGJyPjxicj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTog aXRhbGljOyI+Im91IGJpZW4gc2kgdm91cyBzb3VoYWl0ZXogdHJhZHVpcmUgc2FucyB2b3VzIGVt YmFycmFzc2VyIGRlcyBwcm9ibOhtZXMgZGUgZm9ybWF0YWdlLCBlbiBzaW1wbGUgZmljaGllciB0 ZXh0ZSBvdQogaHRtbC4iPC9zcGFuPjxicj48YnI+Q2EgYXVzc2kgamUgcGV1eCBmYWlyZTogZW52 b3llciBzb3VzIGZvcm1lIGQndW4gZmljaGllciB0eHQuIERhbnMgY2UgY2FzLCBjZSBzZXJhIGF1 IGNvcnJlY3RldXIgZGUgbWV0dHJlIGxlcyBiYWxpc2VzPzxicj48YnI+WQphIHQnaWwgYXVzc2kg bGEgcG9zc2liaWxpdOkgZCdlbnZveWVyIGwnYXJ0aWNsZSBvcmlnaW5hbCBhdSBmb3JtYXQgdHh0 PwooTGEgcHJvY+lkdXJlIG5lIG1lbnRpb25uZSBwYXMgc291cyBxdWVsIGZvcm1hdCBsJ2FydGlj bGUgZXN0IGVudm956Sk8YnI+PGJyPkTpc29s6SBhdmVjIG1lcyBxdWVzdGlvbnMgZOliaWxlcyBk ZSBk6WJ1dGFudCwgbWFpcyBqZSBk6WJ1dGUgYXZlYyBsZSBmb3JtYXQgZG9jYm9vay4uLjxicj48 YnI+PGJyPjxkaXY+S2FtYWwgU2F3YWwgVE9VUkU8L2Rpdj48YnI+PGJyPi0tLSBFbiBkYXRlIGRl Jm5ic3A7OiA8Yj5NYXIgMy4zLjA5LCBqZGQgPGk+Jmx0O2pkZEBkb2Rpbi5vcmcmZ3Q7PC9pPjwv Yj4gYSDpY3JpdCZuYnNwOzo8YnI+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OiAycHgg c29saWQgcmdiKDE2LCAxNiwgMjU1KTsgbWFyZ2luLWxlZnQ6IDVweDsgcGFkZGluZy1sZWZ0OiA1 cHg7Ij5EZTogamRkICZsdDtqZGRAZG9kaW4ub3JnJmd0Ozxicj5PYmpldDogUmU6IFtUcmFkdWNd IHByb2Js6G1lPGJyPsA6ICJ0cmFkICZndDsmZ3Q7ICJ0cmFkdWMub3JnIiIgJmx0O3RyYWR1Y0B0 cmFkdWMub3JnJmd0Ozxicj5EYXRlOiBNYXJkaSAzIE1hcnMgMjAwOSwgMTRoNDA8YnI+PGJyPjxw cmU+amRkIGEg6WNyaXQgOjxicj48YnI+Jmd0OyAqIGlsIG1hbnF1ZSBzdXIgbGUgd2lraSBsYSBt YWNybyAmbHQ7Jmx0O1RhYmxlT2ZDb250ZW50cyZndDsmZ3Q7PGJyPjxicj5lcnJldXIgZGUgbWEg cGFydC4gSWwgbid5IHRvdXQgc2ltcGxlbWVudCBwYXMgZGUgdGl0cmVzIChzZXVsZW1lbnQgZHU8 YnI+dGV4dGUgZW4gZ3Jhcyk8YnI+PGJyPmRvbmMgbGUgZOlmYXV0IHZpZW50IGR1IHNvdXJjZSBl dCBkdSB0cmFkdWN0ZXVyLCBwYXMgZHUgc2NyaXB0IGRlPGJyPmNvbnZlcnNpb24sIGxhIG3qbWUg ZXJyZXVyIOl0YWl0IHByb2JhYmxlIGRhbnMgbGUgeG1sPGJyPjxicj5qZGQ8YnI+PGJyPi0tCiA8 YnI+aHR0cDovL3d3dy5kb2Rpbi5uZXQ8YnI+aHR0cDovL3ZhbGVyaWUuZG9kaW4ub3JnPGJyPmh0 dHA6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj10LWVpYzhNU1NmTTxicj5odHRwOi8vd3d3LmZh Y2Vib29rLmNvbS9wcm9maWxlLnBocD9pZD0xNDEyMTYwNDQ1PGJyPjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MaXN0ZSBkZSBkaXNjdXNzaW9u IFRyYWR1Yzxicj5UcmFkdWNAdHJhZHVjLm9yZzxicj5odHRwOi8vd3d3LnRyYWR1Yy5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFkdWM8YnI+Wy8hXCBMZXMgcGnoY2VzLWpvaW50ZXMgZG9pdmVudCBh dHRlbmRyZSBsJ2FwcHJvYmF0aW9uIGR1PGJyPm1vZOlyYXRldXIuXTxicj48L3ByZT48L2Jsb2Nr cXVvdGU+PC90ZD48L3RyPjwvdGFibGU+PGJyPgoKCgogICAgICA= --===============9164335090573668990==--