e-t172.net

Si vous utilisez le fort pratique script Perl « rrsync », livré avec la distribution de rsync, et permettant de contraindre un client utilisant une clé SSH spécifique à rester dans un répertoire précis et uniquement celui-là (un chroot virtuel, en quelque sorte), il y a de fortes chances pour que ce script échoue lamentablement une fois la mise à jour vers la version 3.0.0 de rsync effectuée, et ce même si vous utilisez le rrsync se trouvant dans la nouvelle version. Vous aurez alors l’occasion de faire connaissance avec ce sympathique message d’erreur :

rrsync: invalid rsync-command syntax or options

En effet, sous certaines conditions, lorsque le rsync client lance son homologue côté serveur, il lui passe certaines options qui n’existaient pas dans la version précédente de rsync. Voici une ligne de commande (lancée en interne par rsync sur le serveur) type rsync < 3.0.0 :

rsync --server --sender -logDtpr . ./

Et voici une ligne de commande type rsync >= 3.0.0 :

rsync --server --sender -logDtpre.iL . ./

On constate que de nouveaux caractères font leur apparition : e.iL. A quoi correspondent-ils ? Notez que les options de rsync lorsque celui-ci fonctionne avec --server (qui est une option interne « cachée », cf rsync(1)) sont légèrement différentes de celles utilisées en mode « normal ». On trouve une explication de ces nouveaux caractères dans le fichier options.c de rsync, fonction server_options() :

/* We make use of the -e option to let the server know about any
 * pre-release protocol version && some behavior flags. */
argstr[x++] = 'e';
#if SUBPROTOCOL_VERSION != 0
if (protocol_version == PROTOCOL_VERSION) {
	x += snprintf(argstr+x, sizeof argstr - x,
		"%d.%d", PROTOCOL_VERSION, SUBPROTOCOL_VERSION);
} else
#endif
	argstr[x++] = '.';
set_allow_inc_recurse();
if (allow_inc_recurse)
	argstr[x++] = 'i';
#if defined HAVE_LUTIMES && defined HAVE_UTIMES
argstr[x++] = 'L';
#endif

On constate que :

• L’option « e » sert à informer le rsync côté serveur du protocole utilisé par le rsync côté client au cas où les deux rsync auraient des versions de protocole différentes. En fait, rrsync gère l’option « e », mais s’attend à la trouver sous cette forme : « eX.Y », où X et Y sont des nombres représentant respectivement le protocole et le sous-protocole utilisé. Or, ici, on voit que cette option peut également s’écrire simplement « e. » lorsque les protocoles sont de même version, ce que rrsync ne reconnaît pas, d’où erreur.
• L’option « i » n’est pas reconnue par rrsync, d’où erreur.
• L’option « L » est reconnue par rrsync.

Pour corriger le problème, il faut donc modifier rrsync pour ajouter la nouvelle option « i » et la nouvelle syntaxe « e. ».

J’ai concocté un patch qui effectue ces modifications : rrsync-bug-3.0.0.patch.

Rédigé par e-t172 | Pas de commentaire »

Dans les grands problèmes existenciels qui forment ce monde, nous pouvons en citer un, et pas des moindres : l’attente des sous-titres de certaines séries, telles que Battlestar Galactica.

En effet, l’équipe des Lords Of Kobol, principale productrice de sous-titres pour cette série, ne met pas moins d’une semaine pour sortir les sous-titres après la sortie de l’épisode. Ces derniers se justifient par des sous-titres de très bonne qualité (ce que je leur concède).

Néanmoins, Keger et moi avons décidé de tenter l’expérience du sous-titrage « pour le fun », juste pour se faire une idée du travail et du temps nécéssaire par nous-mêmes.

Il semblerait que cette expérience ait été concluante, car après une journée de travail, nous avons réussi, avec l’aide de ma soeur, à produire des sous-titres en VO et VF de qualité acceptable.

Vous pouvez les télécharger à l’emplacement suivant : Sous-titres Battlestar Galactica 3×03 Exodus VO/VF pour releases YEM et EZTV.

Par ailleurs, ces derniers sont distribués sous licence Creative Commons BY, ce qui signifie, en gros, que vous pouvez en faire tout ce que vous voulez, à condition de citer l’auteur. En cela nous nous démarquons encore des autres équipes de sous-titrage, qui interdisent jalousement toute redistribution en dehors des sites qu’ils ont choisis.

Je tiens à préciser qu’il s’agit d’une expérience ponctuelle. Nous ne savons pas encore si nous allons faire de même pour les prochains épisodes à venir.

En dernier lieu, je tiens à signaler le comportement pour le moins puéril de certains sites de séries (Projet-SG, SeriesTele), qui visiblement tiennent plus que tout à leur gloire et à leur popularité et qui à ce titre ont systématiquement censuré toutes nos tentatives de signalement sur leurs forums, au lieu de penser à l’intérêt général, ce qui est pourtant censé être leur but.

Rédigé par e-t172 | 24 commentaires »

Forom.com est un site consacré, comme son nom ne l’indique pas, aux séries télévisées. Il est notamment consulté pour ses sous-titres d’épisodes, qui possèdent l’avantage de sortir particulièrement rapidement tout en gardant une qualité remarquable.

Si vous ne l’avez pas déjà fait, je vous invite à y faire un tour. Mais attention : avant cela, il est de votre devoir de vous préparer psychologiquement à ce que vous allez affronter. Respirez un grand coup, et préparez-vous à accéder à un site qui mériterait 100 fois de figurer dans les manuels d’informatique, section « Tout ce qu’il ne faut PAS faire lorsqu’on conçoit / développe un site web ».

Il y a de quoi pleurer d’indignation, ou se pisser dessus de rire, au choix. Non seulement les pages principales sont entièrement en Flash sans aucune raison valable, avec tous les bien connus problèmes inutiles que cela crée (accessibilité, ergonomie, URLs inopérantes, impression papier, lourdeur, et j’en passe et des meilleures), mais en plus de cela le site est constitué d’un très curieux mélange de pages HTML et de Flash, ce qui rend l’aspect graphique du site complètement disparate et la navigation digne du parcours du combattant. Rajoutez à cela le fait que les pages HTML sont hideuses, que le site tente d’ouvrir une demi-douzaine de popups (ou presque) à chaque page, et que tout le site en général est une effigie de l’artisanat constellée d’erreurs de développeur débutant et vous obtenez de quoi faire vomir un ornythorinque affamé (c’est du vécu).

Mais bien évidemment, ce billet ne serait pas très utile si il ne se contentait que de pointer du doigt ce prétendu « site internet ». Je compte bien ouvrir la voie pour que toi, amateur de séries télévisées en quête de sous-titres, te soit épargné le passage tortueux mais jusqu’ici obligé accueil -> connexion -> rubriques -> catégorie alphabétique -> nom de la série -> séléction du sous-titre. En effet, Forom, dont les dirigeants n’ont visiblement rien compris à l’intérêt des liens hypertextes, possède un système destiné à empêcher toute personne de télécharger des sous-titres sans passer d’abord par la procédure susdite. En particulier, il empêche tout accès direct à la page listant les fameux fichiers.

Cette limitation est en passe d’être résolue, car votre serviteur a, en coopération avec votre second serviteur ApOpH!s, cassé ce système de protection. Les informations recueillies permettront, à terme, de développer des scripts permettant de « parser » (analyser) les pages contenant les sous-titres de manière à en extraire les informations utiles afin de les placer dans un flux RSS utilisable par un agrégateur - donnant ainsi à l’utilisateur un moyen pratique de suivre les sorties des nouveaux sous-titres.

Toute la protection est contenue dans un code de sécurité placé dans l’URL des pages contenant les documents du site (paramètre « c=… »). Evidemment, vous pourriez penser qu’il s’agit d’un code unique de session - lequel aurait été impossible à cracker - mais en réalité, ce n’est rien de cela. Grâce à Flare, un programme conçu pour décompiler un objet Flash SWF et en extraire le code source, j’ai pu isoler l’algorythme (quoique, je ne sais pas si on peut utiliser ce terme pour une telle… « chose ») utilisé pour générer ce code de sécurité. Il semblerait que les développeurs de Forom aient été assez naïfs (ou plus probablement, incompétents) pour croire qu’un objet Flash ne pouvait pas être décompilé, ce qui est bien évidemment complètement faux.

Voici l’algorythme en question. Je vais devoir, une fois de plus, vous demander de vous préparer psychologiquement à ce que vous allez lire (et de bien protéger votre clavier d’éventuels éclaboussures peu reluisantes). Si vous avez des notions de base en cryptologie, je vais devoir vous demander de rester calme et de ne pas céder à la panique. C’est parti.

• Le nom d’utilisateur est d’abord mis en majuscules.
• Pour chaque lettre du nom d’utilisateur : ajouter une lettre aléatoire de 97 à 122 + le code ASCII de la lettre du nom d’utilisateur
• Ajouter « z »
• Ajouter le code ASCII du premier caractère du mot de passe
• Pour chaque lettre du mot de passe (sauf la première) : ajouter une lettre aléatoire de 97 à 121 + le code ASCII du caractère du mot de passe
• Ajouter « z »
• Ajouter les 5 premiers chiffres de l’adresse ip du client en ordre inversé
• Ajouter un caractère aléatoire

Une fois ce code généré, vous pouvez accéder à n’importe quelle page de documents de Forom.com sans même vous « logger ».

Ah, j’en vois qui au fond de la salle qui n’ont pas encore terminé leur fou rire. Pour cette raison, un petit interlude :

Voilà. Maintenant que tout le monde s’est remis de cette découverte, je tiens à préciser que en dévoilant cette information je ne viole aucun droit d’auteur (pas directement, en tout cas), n’effectue aucune intrusion dans un système informatique et n’ai volé aucune donnée à qui que ce soit. Par ailleurs, je me conforte dans l’idée que cette nouvelle va, espérons le, inciter l’équipe de Forom de se remettre un peu en question et de recruter un vrai concepteur / développeur de sites Internet, pas un glandeur du dimanche. Par ailleurs, tout commentaire du style « oh c’est pas bien ce que tu fais » ou « t’as qu’à le faire toi même le site si t’es pas content » sera immédiatement supprimé pour cause d’inutilité flagrante.

EDIT : il semble que l’accès aux pages contenant les listes de sous-titres soit un poil plus compliqué que ce que je croyais au départ, car la page de sous-titres vérifie la validité d’un cookie de session que la page principale des sous-titres (celle contenant la liste des séries) a déposé. Si vous comptez développer un quelconque script, il vous faudra donc d’abord récupérer un cookie de session valide sur cette page avant de le renvoyer sur la page contenant la liste des fichiers de sous-titres. Vous l’aurez compris, ce système est tout aussi stupide et inutile que le reste.

Rédigé par e-t172 | 20 commentaires »

Depuis Dedibox, il est rentré dans mes habitudes de réinstaller entièrement un serveur dédié une fois qu’il m’a été livré. Oui, entièrement, distribution y comprise. J’y vois deux intérêts principaux :

• Vous pouvez installer des distributions non proposées en standard par votre fournisseur de serveur dédié.
• C’est plus propre. En effet, je n’aime pas les systèmes préconfigurés qui sont, le plus souvent, conçus pour les débutants avec un nombre incroyable de choses à reparamétrer. Par ailleurs, j’ai l’habitude de travailler exclusivement avec la version Unstable de Debian (même en production, sisi, et je ne suis pas fou) ; or, mettre à jour la Sarge proposée par OVH vers Unstable est une opération assez sale, qui laisse des traces de l’ancienne configuration un peu partout. D’une manière générale, il est donc plus judicieux de réinstaller entièrement le système afin d’avoir un meilleur contrôle sur ce dernier.
• Si votre fournisseur propose un mode « rescue » mais pas de partionnement personnalisé, vous pouvez utiliser le rescue pour faire votre propre partionnement.
• Dans le cas des serveurs dédiés d’OVH dotés d’un processeur 64 bits (notamment le Start 310G, le nouveau serveur d’Agrégaweb), il est impossible de demander l’installation de la version AMD64 de Debian. L’avantage de la réinstallation devient dès lors indéniable, car on peut alors installer une Debian AMD64, et profiter ainsi des avancées de cette architecture. Ainsi, le nouveau serveur d’Agrégaweb tourne sous Debian AMD64.

Mais, me diriez-vous, comment cela est-il faisable sans accès physique à la machine, seulement un accès SSH ? En fait, la possibilité d’effectuer la manipulation dépend de 3 conditions : la présence d’un système de réinstallation gratuite du serveur (pour remettre celui-ci à sa configuration d’usine « au cas où »), la présence d’un système dit « rescue » (système d’exploitation distant minimal conçu au départ pour être utilisé en cas de pépin sur la machine), et la présence d’un système de partionnement personnalisé du (des) disque(s) dur(s) du serveur ^[1]. Les relations entre ces différentes conditions étant plutôt complexes, je les ai regroupées dans un tableau :

De là, vous avez deux méthodes à votre disposition pour mettre en place votre nouveau système :

• Installer directement le système d’exploitation depuis l’ancien système ou le système rescue : cela n’est uniquement possible que si l’OS que vous vous apprêtez à installer propose une installation « à chaud », c’est à dire sans support sur lequel vous aurez besoin de rebooter (vous faites l’installation entièrement à partir d’un système existant). Debian (via l’utilitaire debootstrap) et Gentoo, entre autres, le proposent. C’est la solution la plus propre et la plus fiable.
• Préfabriquer une image : c’est la seule solution possible si la distribution visée ne propose pas d’installation à chaud. La méthode consiste à installer entièrement le système chez vous, en faisant « comme si » vous étiez sur le serveur dédié, puis à recopier une image du système ainsi créé sur votre serveur dédié, sur laquelle vous pourrez ensuite booter. L’avantage est que cela fonctionne pour tous les systèmes d’exploitation ^[4], l’inconvénient est que le système obtenu peut se révéler plus ou moins propre puisqu’il n’a pas été installé sur son environnement matériel final - avec la plupart des distributions Linux, le système installé est le même quel que soit le matériel, mais ce n’est peut-être pas le cas pour d’autres types de systèmes. Par ailleurs, cette méthode est plus compliquée et très peu d’aide existe sur Internet pour effectuer ce genre d’opération.

Etant donné que les seules réinstallations que j’aie effectuées concernaient des Debian Unstable installées à chaud, je ne peux pas vous en dire plus sur la deuxième méthode. Voici quelques conseils :

• Lors du partitonnement initial, placez le système préinstallé par votre fournisseur dans une petite partition (2 Go par exemple) au début du disque dur, puis placez la ou les partitions sur lesquelles sera installé votre nouveau système. Ne placez pas de swap à ce stade ^[5]. Ensuite, lorsque le nouveau système est en place, remplacez la première partition contenant l’ancien système, devenue inutile, par une partition de swap qui servira à votre nouveau système. D’autres variantes sont évidemment possibles, menant au même résultat.
• Evidemment, il est plus confortable d’installer le nouveau système depuis l’ancien préinstallé que depuis le système rescue, sauf si vous n’avez pas le choix ^[2].
• Si vous hésitez lors de la configuration du nouveau système (par exemple, si elle dépend d’une particularité du matériel dont vous n’avez pas connaissance), gardez à l’esprit que la configuration de votre ancien système est une précieuse mine d’informations, car elle, on est sûr qu’elle fonctionne.
• Si vous tentez d’utiliser la première méthode pour installer un système 64 bits à partir d’un système 32 bits (pour les processeurs de type x86_64), bootez d’abord sur votre ancien système avec un kernel compilé pour du 64 bits, sinon vous ne pourrez pas utiliser les binaires de votre nouveau système dans l’ancien : typiquement, vous voudrez sûrement faire un chroot sur votre nouveau système avant de booter dessus, pour installer des packages par exemple, or vous ne pourrez pas le faire depuis un kernel 32 bits car tous les binaires contenus dans le chroot refuseront de fonctionner tant qu’ils ne tournent pas sur un kernel conçu pour les processeurs x86_64. (notons par ailleurs que debootstrap crée des environnements chroot pour installer les packages de base, debootstrap refusera donc de terminer l’installation d’une Debian AMD64 à partir d’un kernel 32 bits).
• Faites en sorte que votre premier boot se fasse sur un système le plus simple possible pour éviter tout oubli ou erreur de configuration : installez un Kernel générique, préférez le bootloader LILO à GRUB (j’ai commis l’erreur d’installer directement GRUB sur un serveur OVH, alors que ce dernier ne le supportait pas, et cela m’a fait perdre de nombreuses heures de travail), configurez les interfaces réseau en statique (et non DHCP) de préférence. Si vous voulez un système plus complexe, modifiez-le après coup.
• Avant d’essayer de booter sur votre nouveau système, vérifiez bien que vous n’avez rien oublié. Assurez vous du bon fonctionnement de toute la chaîne de boot jusqu’au lancement des services de contrôle à distance : rappellez-vous que le système que vous allez installer doit passer du bootloader au serveur SSH (par exemple) sans oublier les interfaces réseau, et que tout cela doit se faire sans anicroche, surtout si vous n’avez pas de système rescue pour rectifier le tir après coup, ou si ce dernier devient inutilisable (par exemple si votre OS utilise un système de fichier non reconnu par le système rescue, ce qui sera très probablement le cas si vous tentez d’installer un système exotique). La vérification du kernel sur lequel le premier boot se fera, ainsi que de la configuration du bootloader, méritent une attention particulière.
• Attention, lors des premiers boots, les problèmes survenant avant le montage des systèmes de fichiers (c’est à dire au niveau du bootloader ou du kernel) ne pourront pas être consignés dans des logs, ce qui vous contraindra à les rechercher à l’aveuglette. Soyez méthodique dans la recherche du problème et procédez par élimination.

Bonne chance !

[1] Curieusement, OVH ne propose le partitionnement personnalisé que lors de la réinstallation gratuite, jamais lors de la première installation. Donc, contrairement aux apparences, les clients d’OVH se trouvent dans le cas 1 du tableau.

[2] Les administrateurs souhaitant utiliser le système rescue pour installer leur nouveau système ET planifiant d’installer un nouveau système 64 bits doivent au préalable s’assurer que le système rescue proposé tourne sur un kernel 64 bits ^[3].

[3] Cette restriction ne s’applique pas si vous souhaitez installer votre nouveau système depuis une image préfabriquée (méthode 2).

[4] Oui, même Windows ! Certains ont déjà réussi à l’installer sur une Dedibox par cette méthode ; néanmoins, elle demande un certain nombre de compétences préalables en administration de systèmes Windows pour être exploitable.

[5] Certains systèmes de partitionnement particulièrement mal foutus (tels celui d’OVH) vous obligent à choisir une partition de type swap, dans ce cas placez-là en lieu et place d’une autre partition et recréez ensuite un système de fichiers normal sur la partition contenant le swap depuis le système préinstallé.

Rédigé par e-t172 | 2 commentaires »

Protège ton ordi est une initiative de l’Education Nationale incitant les enfants et leurs parents à sécuriser leur ordinateur sur Internet.

Dommage, ce n’était pas une mauvaise idée…

Rédigé par e-t172 | 14 commentaires »