Le petit coin de Nicolas

Recherche développeur PHP - Symfony pour un annuaire d'entreprise à JCDecaux

Nicolas Steinmetz — Thu, 11 Mar 2010 15:29:00 +0100

Ci-après le descriptif de la mission :

Mission :

Conception et développement du nouvel annuaire d’entreprise Globe.

Les travaux relatifs à la mission seront :

Participation à la spécification détaillée du système constitué d’une base de données, d’une IHM de consultation et d’un ensemble de traitements batch
Conception et réalisation en PHP / Symfony (incluant les tests unitaires)
Elaboration des tests de qualification du système

Environnement technique :

PHP 5.2.x
Framework Symfony
MySQL 5.0/5.1
Microsoft Active Directory
Redhat 5.x

Compétences techniques requises :

Rédaction de spécifications détaillées
Framework Symfony et PHP
Modèle relationnel, requêtes SQL

Compétences techniques appréciées :

SQL Oracle (l'existant est stocké dans une base Oracle)
Javascript et jQuery
VBS (Visual Basic Script) (pour la réalisation de scripts - compétence non bloquante car pourra au pire être réalisée en interne)
Active Directory

Qualités humaines recherchées :

Esprit d’analyse
Rigueur
Dynamisme
Sens de la communication

Localisation du poste :

Plaisir ZI Sainte-Apolline (78)
Pas de télé-travail possible pour cette mission

Date de démarrage souhaitée :

Au plus tôt

Durée de la mission :

50 jours sur 3 mois

Contact :

nicolas POINT steinmetz AT jcdecaux POINT fr

Extension Postgres pour PHP sous Slackware

Nicolas Steinmetz — Sat, 06 Mar 2010 21:35:00 +0100

Par défaut, la version de PHP fournie par Slackware ne comprend pas les extensions pgsql et pdo_pgsql, chose que nous allons corriger dans un instant :

Pour commencer, récupérer le slackbuild de PHP pour votre version de Slackware :

rsync -avz --del rsync://slackware.mirrors.tds.net/slackware/slackware64-13.0/patches/source/php ./
rsync -avz --del rsync://slackware.mirrors.tds.net/slackware/slackware64-13.0/source/n/alpine ./

Pour PHP, on s'appuie sur les patchs car la version par défaut dans Slackware 13.0 est PHP 5.2.10 et que par la suite il y a eu une mise à jour en PHP 5.2.12. Pour alpine, il s'agit d'une dépendance afin de pouvoir compiler l'extension imap de PHP. Il n'y a pas eu de mise à jour d'alpine depuis la sortie de Slackware 13.0 donc on le prend dans les sources originelles.

Editez ensuite php/php.Slackbuild pour y ajouter les informations relatives à Postgres dans le cadre du configure, à savoir :

--with-pgsql=shared,/usr \
--with-pdo-pgsql=shared,/usr \

Ce qui me donne au final (et avec au passage modification du BUILD pour le distinguer du paquet officiel)

BUILD=${BUILD:-1_slack13.0_with_pgsql}
 
[...]
 
  --with-mysql=shared,/usr \
  --with-mysqli=shared,/usr/bin/mysql_config \
  --enable-pdo=shared \
  --with-pdo-mysql=shared,/usr \
  --with-pdo-sqlite=shared \
  --with-pgsql=shared,/usr \
  --with-pdo-pgsql=shared,/usr \
  --with-pspell=shared,/usr \
  --with-mm=/usr \
 
[...]

Ensuite il faut éditer le fichier doinst.sh pour que les extensions relatives à Postgres soient chargées ; il y a surement plus propre comme méthode mais ça marche :

echo "extension=pgsql.so" >> /etc/httpd/php.ini
echo "extension=pdo_pgsql.so" >> /etc/httpd/php.ini

Ne pas oublier de re-gzipper à nouveau doinst.sh pour qu'il soit pris en compte par le slackbuild :

gzip doinst.sh

Une fois cela effectué, pour générer la création de votre package PHP, il vous suffit de faire :

./php.SlackBuild

Une fois généré, pour l'installer :

removepkg php
installpkg /tmp/php-5.2.12-x86_64-1_slack13.0_with_pgsql.txz

Pour ceux qui veulent récupérer le slackbuild ou bien le package 64 bits :

Pour ceux qui ne sont pas en 64 bits, il suffit de recompiler en précisant dans php.Slackbuild :

ARCH=${ARCH:-i486}

Et voilà...

Eviter le kernel panic en mettant à jour vers slackware current

Nicolas Steinmetz — Sat, 06 Mar 2010 10:08:00 +0100

Par curiosité, j"ai voulu voir ce que pouvait donner slackware-current (le branche "bleeding-edge" de slackware) et dans un premier temps bien mal m'en a pris vu que cela s'est terminé par un joli "Kernel Panic". Après discussion avec un collègue et un peu de recherche sur internet, il s'avère qu'à partir du noyau linux 2.6.32, Slackware a désactivé la vieille couche IDE qui faisait que les périphériques étaient vus en /dev/hd*.

Voici la manipulation à suivre pour passer d'une slackware 13.0 à slackware current :

Tout d'abord, utiliser un mirroir slackware-current en éditant /etc/slackpkg/mirrors en lieu et place du mirroir de la version stable. Mettre à jour ensuite votre distribution :

slackpkg update gpg
slackpkg update
slackpkg install-new
slackpkg upgrade-all

A ce stade, votre système est à jour et vous avez un joli noyau 2.6.33 en passe de devenir votre noyau par défaut.

Avant de redémarrer votre machine, il faut faire les manipulations suivantes :

Edition de /etc/lilo.conf pour remplacer les occurrences de /dev/hd* par /dev/sd*
Edition de /etc/fstab pour remplacer les occurences de /dev/hd* par /dev/sd*
Suppression de /etc/udev/rules.d/70-persistent-cd.rules ; Le fichier sera régénéré correctement au redémarrage de la machine
Si vous utilisez initrd au démarrage, il faut éditer /boot/initrd-tree/rootdev et regénérer votre image initrd via mkinitrd. Dans mon cas avec une installation de base de slackware, je n'en ai pas eu besoin. Par contre, j'en aurai besoin pour mon linutop.

A ce stade, si vous faites un lilo -v pour prendre en compte vos modifications, il va hurler puisqu'il ne trouve pas de périphérique /dev/sd*.

Pour cela il suffit de tricher un peu (ma partition /boot est sur /dev/hda2) :

ln -s /dev/hda /dev/sda
ln -s /dev/hda1 /dev/sda1
ln -s /dev/sda2 /dev/sda2
lilo -v
reboot

Au redémarrage, udev remplacera vos liens symboliques /dev/sd* par les bonnes entrées qui vont bien.

Vais pouvoir aller tester KDE 4.3.5 en attendant que KDE 4.4.x arrive dans slackware-current du coup...

Source : Robby’s libata switchover howto

Pour ceux qui utiliseraient encore une url en unelectronlibre.info

Nicolas Steinmetz — Wed, 27 Jan 2010 04:14:00 +0100

Le domaine expire demain et ne sera pas renouvelé puisque cela fait plus d'un an que tout a migré sur http://nicolas.steinmetz.fr avec les redirections permanentes qui vont bien

Pour les 219 abonnés (tout ça ? merci à vous ) qui utilisent l'url FeedBurner (http://feeds.feedburner.com/UnElect...), pas de souci, je continue à la maintenir. Rien à changer de ce côté là...

Certains lecteurs voudraient-ils recevoir le flux RSS par email ? C'est maintenant possible...

Un modem peut en cacher un autre

Nicolas Steinmetz — Tue, 26 Jan 2010 23:00:00 +0100

Ci-après ma contribution à Polar Geek, initiative pour le moins ingénieuse de Bruno Bord.

Mon téléphone s'agita, le message fut bref :
- "Rendez-vous au Bar de la Taupe à 15 heures"
J'eus à peine le temps d'assimiler le message que l'appel était fini. Sortant de ma torpeur, je notais rapidement le message sur un bout de papier tant qu'il résonnait encore en ma mémoire. Je ne connaissais qu'une personne en mesure de me passer ce type d'appel et cela faisait bien des années que je n'avais pas entendu cette voix. Me réveillant doucement en sirotant mon café, je songeais à ce message et surtout à son émetteur. Les souvenirs remontaient au fur et à mesure et ma mémoire commençait à rassembler des bribes de visage dans mon esprit. Rigolo, il se rappelait que j'évitais de travailler en début d'après-midi pour cause de digestion et de sa sieste associée. Il ne prenait aucun risque quant à ma disponibilité de me fixer un rendez-vous à 15h dans ce lieu... Il était donc toujours de la partie ? J'aurais pensé qu'il aurait fini par renoncer... L'après-midi s'annonçait intéressant et pour le moins intrigant...

La matinée passa machinalement avec son lot de paperasses et ses coups de téléphone. Les quelques affaires en cours n'avaient pas grand intérêt mais me permettaient de payer mon toit, mon manger et les croquettes du chat. Pour ne pas rater mon rendez-vous, je mangeai léger et me rendis en marchant jusqu'au Bar de la Taupe. A défaut de dormir, ce sera une marche digestive...

Le Bar de la Taupe a pour intérêt d'y accueillir une grande diversité de personnes. Des jeunes lycéens crapoteurs aux cadres tirés à quatre épingles, il se transformait en "salon de thé" tous les jeudi après-midi pour y accueillir un groupe de mamies terribles, plus portées sur le panaché que le thé et plus sur leurs parties de poker que leur tricot. Je m'assis donc en terrasse, afin de profiter des quelques rayons de soleil et commandai mon café. A peine eus-je le temps de poser ma veste qu'il arriva. Il n'avait pas changé malgré toutes ces années. Toujours habillé de son vieux costume pastel et de son noeud-papillon, il était maigre comme un clou. De prime abord, il ne ressemblait à rien, beaucoup de personnes s'y étaient laissés prendre et avaient fini par perdre leur dossier contre lui. Denis Zot, alias Papy, s'assit et commanda un café avec son nuage de lait.
" Toujours avocat ?", lançai-je
" Bien évidemment, le petit peuple a besoin qu'on le représente !"
Ainsi, il n'avait vraiment pas changé. Idéaliste jusqu'au bout des ongles, il était le chevalier servant de la justice dans un monde qui grouillait de requins à la solde de gros intérêts privés. Personne n'avait donc eu raison de lui jusqu'à présent ; ça laissait présager de bonnes choses.
"J'ai un dossier pour toi", me dit-il, "c'est urgent et tu es le seul qui peut m'aider"
Perplexe, je le laissais continuer :
"Tes derniers dossiers ne t'ayant pas tenu au fait de l'actualité informatico-légale, il se trouve que depuis plusieurs mois, j'ai mis à mal bon nombre de majors et des membres de nos gouvernements dans leurs tentatives de poursuite d'internautes pour des histoires de copyrights. Au début, cela était assez simple, il suffisait de trouver le vide de procédure pour faire tomber le château de cartes. Même si la presse a peu relayer l'information, j'ai quand même réussi à évincer A. Dopi de toute velléité électorale..."
Ah oui songeais-je. Je m'en souviens maintenant, c'était l'une des dernières informations qu'avait remonté un vieux script en analysant des flux RSS que je pensais périmés. Depuis l'avénement des "Etats Majors" en lieu et place des "Etats Nations" au début du 21ème siècle, la presse était sous contrôle et il était de plus en plus complexe d'échapper à la propagande d'Etat. Le modèle Chinois s'était imposé de part le monde, toute l'information était contrôlée par l'une des cinq Majors et les bribes de gouvernement qui restait ne faisait que leur obéir aveuglément. Arrestations sommaires et mise sur écoute se faisaient à tour de bras. Papy, en face de moi, faisait donc la résistance et jouait le rôle de Chevalier Blanc du petit peuple. Il devait être considéré comme l'ennemi public n°1 ou presque. Il ne devait pas non plus lui rester beaucoup de soutien. Dans quoi allait-il m'embarquer ???
"... mais bon revenons-en à notre affaire" me dit-il. "Mon client, qui comme moi, milite pour le retour aux libertés fondamentales, après moult menaces (comprendre des courriers envoyés par le ministère de la culture pour des activités soit-disant illégales) vient d'être arrêté. S'il ne signe pas un faux aveu, il sera expédié dans son pays natal avec sa femme et ses deux enfants. S'ils repartent en Birmanie, ce sont les pompes funèbres qui vont les accueillir à l'aéroport..."
"Qu'attends-tu de moi ?"
"Trouve la preuve du complot ; seul toi peut la trouver et je n'ai confiance qu'en toi."
"Et j'y gagne quoi ? Hormis de passer sur une liste noire ?"
"Financièrement, donne-moi ton prix et tu l'auras. La question n'est pas là. Comme tu le sais peut-être, la contestation gronde et nous avons besoin d'un coup d'éclat pour faire prendre conscience au reste du peuple que la solution est là. On peut mettre fin au joug des Majors. Ce que je t'offre, c'est la liberté !" Le bougre, il savait que j'étais sensible à ces mots et que je ne supporterais pas que l'on puisse faire du mal à des enfants. Et puis financièrement, je n'avais pas trop le choix, je commençais à prendre les raviolis en grippe...
"Ok, j'accepte ; qu'as tu pour moi ?"
"La clé de sa maison, la milice du Ministère de la Culture ne s'y est pas encore rendue. Ils iront demain d'après un de mes informateurs. C'est ton unique chance de trouver les preuves de son innocence avant qu'ils ne déposent les fausses. C'est tout ce que j'ai pour toi..."
"Bien, j'y vais de ce pas..."
"Fais attention à toi et surveille bien tes échanges" me dit-il. Alors qu'il se levait pour partir il me dit "Tu en auras besoin aussi : Pomme Noisette" et il disparut.

Je finis d'un trait mon café, payai l'addition. Je repartis au bureau mais plutôt que de monter à l'étage, je pris le chemin de la cave. Il me fallait du matériel spécifique et qu'on ne remonte pas jusqu'à moi si je me faisais prendre. Je ne faisais aucunement confiance au matériel dernier cri qui était sur mon bureau. Pour mes affaires courantes, cela allait bien mais pas pour des situations comme celles-ci. Je ressortis mon petit netbook sous Slackware en disant "Hello Citrouille, j'ai du boulot pour toi". Au moins avec Slackware, on sait que l'on installe les sources officielles. Pas de risque de rootkit ou autre tripatouillage exotique. Le temps de vérifier le bon état des batteries et de son bon fonctionnement et je prenais la direction de la maison du client de Papy.

La maison était située en banlieue Ouest de Paris. Elle était au milieu d'une résidence calme et agréable. Un bon coin pour une vie de famille songeais-je. Un jour peut-être... Après avoir fait un petit tour de la maison pour vérifier de la véracité des propos de l'informateur de Papy, je m'y introduisis sans problème. Pas de voisine curieuse pour casser mon approche, vraiment chouette ce quartier. L'intérieur était propre et bien rangé. Quelques jouets dispersés témoignaient de la présence d'enfants.
Je m'attelais au travail et cherchais les ordinateurs. Une fois le premier trouvé, je remarquai que le réseau était filaire. Chose étrange de nos jours mais trahissant le coté paranoïaque du client. En effet, le Wifi s'était imposé comme mode d'accès par défaut mais sa médiocre sécurité permettaient une écoute des plus aisées par nos milices étatiques ou la multitudes de sociétés privées dont les résultats étaient basées sur la délation d'internautes. Au moins avec un réseau filaire, il est aisé de trouver les différents ordinateurs. Je dénombrais 2 portables et deux tours, ainsi qu'une sorte de client léger collé sous le bureau, au même niveau que les prises électriques. Avant d'entrer plus loin dans mon investigations, je branchais Citrouille pour vérifier quelques informations supplémentaires : pas de réseau wifi à proximité, donc j'ai bien tous mes PCs.
Je commençais mon analyse par les deux tours situés dans les chambres des enfants. Je les débranchais du réseau et y introduisis ma clé USB magique contenant un OS minimaliste et surtout des outils d'analyse rapide. Ces derniers ne m'apprirent pas grand chose des deux tours. Les logiciels étaient tous en règles et à jour et les données étaient celles d'un ordinateurs d'enfant : des photos, des jeux vidéos, quelques listes aux Père Noel et quelques menues bricoles. La seule chose repérée fut la présence d'un proxy. Tiens, le père de famille semble vouloir protéger ses enfants. Cela doit correspondre au client léger repéré sous le bureau. Passons à autre chose...

Je décidais alors de brancher Citrouille sur le réseau en utilisant le câble réseau d'une des tours pour voir s'il y avait des activités suspectes. J'activais le mode furtif et en lecture seule pour éviter toute intrusion désobligeante. Le temps que Citrouille s'initialise, je poursuivais l'analyse des deux portables. Pour l'un des deux, ce fut facile, il était complètement HS et vue la dose de poussière sur la machine, cela ne datait pas d'hier. Pour le second, il était en veille et tout de suite un mot de passe me fut demandé. J'avais deux solutions pour cet ordinateur : soit le redémarrer sur ma clé usb magique et analyser son contenu au risque de perdre les données actuellement en cours ; soit le sortir de sa veille et l'analyser en direct live, sans trop savoir ce qu'il contenait tant d'un point de vue données que de celui du mouchard. Il me fallait bien sur trouver le mot de passe... Un mouvement de lumière attira mon attention. Je retins mon souffle avant de constater que c'était seulement lié au soleil qui se couchait et dont la lumière se reflétait dans la porte du four. Et là, le déclic : Pomme Noisette pardi ! Le mot de passe en ma possession, cela ne m'aidait pas pour autant sur l'attitude à suivre vis à vis de ce portable.

Mon attention se déporta alors sur le client léger placé sous le bureau. Je connaissais ce genre de modèle, une configuration minimaliste qui ne prend pas de place et qui permet de rendre des services. Une invite me demanda un mot de passe et Pomme Noisette fut le sésame. Mes soupçons étaient justes, la machine faisait bien office de proxy particulièrement agressif. Des tunnels VPN étaient en outre établis et obéissaient à des règles de routage bien particulières. Tout était fait pour protéger les internautes de la maison et anonymiser au maximum certaines pratiques. Le client de Papy est pour le moins paranoïaque et la réalité ne pouvait que lui donner raison. Toutefois, il s'était fait prendre. Il me restait à trouver comment...

Tout d'un coup, Citrouille se mit à biper dans tous les sens. Elle m'indiqua que le réseau contenait une activité anormale de programmes cherchant à récupérer des informations de tout ce qui circulait sur le réseau et/ou à s'introduire sur les machines présentes sur le réseau. A priori, elle ne s'était pas fait prendre mais il allait falloir la jouer finement pour en apprendre un maximum sans se faire prendre ou montrer que quelqu'un cherche à innocenter le client de Papy...
Il me fallait maintenant accéder au contenu du portable à tout prix sans éveiller les soupçons. Du client légér, je récupérais toutes les informations réseau sur le profil du portable (Adresse MAC, etc). Ceci s'ajoutant aux informations produit écrites sur le portable, j'étais en mesure de créer un profil factice sur Citrouille pour se faire passer pour le portable afin de pouvoir l'analyser tranquillement. Alors que je notais les informations sur un bout de papier, je notais la présence d'un bon de livraison émis par le FAI pour le remplacement du modem/routeur. En y regardant de plus près, cela datait de la semaine précédente... tiens donc. Le courrier stipulait que l'équipe du FAI en charge de la surveillance du matériel avait noté des incidents sur le modem. Par conséquent, un modem de rechange était envoyé de façon préventive et moyennant l'envoi du modem originel pour réparation. Mon radar vit rouge tout de suite, se pourrait-il que le modem soit le responsable de l'histoire ?

Rejoignant Citrouille, je peaufinais mon plan d'attaque. Citrouille allait se faire passer pour le portable et me permettrait d'analyser le modem à son insu en lui donnant des données bidon à manger en masse. Ces données était constituées d'un savant mix de consultations de sites honnêtes, téléchargement de binaires et d'images de femmes plus ou moins dénudées, histoire de faire tilter tout algo de surveillance comme il se doit. Citrouille était prête, il ne me restait plus qu'à taper sur "Entrée". Une pression de touche plus tard et simulant une micro-coupure réseau, Citrouille avait pris la place du portable. J'ouvris alors la session et lança le gestionnaire des tâches ; aucune activité suspecte pour le moment. Il cherchait à se reconnecter sur le réseau mais je ne craignais rien, Citrouille l'empêcherait de revenir en ligne. Je fis une passe rapide sur l'ordinateur. Rapidement je découvris un dossier "Téléchargement" contenant quelques oeuvres piratées à des dates variées. Cela était vraiment trop gros comme pièce à conviction mais à l'heure des Etats Majors, cela suffisait amplement pour vous mettre à l'ombre et vider votre compte en banque. Surtout, cela ne collait pas avec ce que j'avais pu voir précédemment sur le client de Papy. Un Dialer dont le nom contenait celui du FAI chercha alors à s'exécuter ; louche me dis-je et tuait alors le processus. Pour éviter tout autre problème, j'arrêtai l'ordinateur pour une analyse ultérieure. Mon regard revint sur le modem, qui de ses diodes me narguait, je le savais...

Citrouille me donna la solution. De nombreuses connexions avaient cherché à se connecter sur le portable pour récupérer moult informations et surtout y placer les mêmes fichiers que ceux que j'avais vu dans le dossier "Téléchargement". Je le tenais mon coupable et il devenait aisé de reconstituer l'histoire. En recevant son nouveau modem, le client de Papy bien qu'habituellement derrière son proxy, dut pour une fois se connecter en direct au modem. A ceci s'ajoutant le CD d'installation dont venait surement le Dialer (et surement d'autres exécutables peu catholiques), le portable avait été compromis à ce moment là. Les autorités n'avaient alors plus qu'à attendre que le modem fasse son travail et de saisir l'individu quand bon leur semblait. L'énigme était résolue, je remis les choses en ordre et quittais discrètement la maison du client de Papy.

La fin de l'affaire fut explosive. Après avoir fait part de mes découvertes à Papy, celui-ci contacta différents collectifs et associations en faveur de la liberté pour créer un effet presse hors du commun. Lorsque la communication fut lancée, les autorités ne purent la retenir et elle déferla sur l'espace public. Le quidam moyen s'empara du sujet et des manifestations spontanées eurent lieu aux quatre coins du pays. L'opposition bien qu'affaiblie tira son épingle du jeu en faisant part de son expérience à ce mouvement citoyen qui grossissait de façon exponentielle. Le gouvernement chercha à faire sauter quelques fusibles en la présence de Monsieur Lop Psi et d'A. Cta mais cela ne suffit pas. Après un mois de manifestation, il fut contraint à la démission et de désapprouver les Majors. Un nouveau gouvernement fut élu et il s'empressa de rétablir bon nombre de libertés fondamentales bafouées depuis tant d'années, ainsi que la neutralité du net. Quelques FAI jugés trop proches des Majors firent faillite et il fut décider de confier les accès à internet à des associations citoyennes.

Personnellement, je savourais cette victoire même si je regrettais de ne pas avoir demandé une rémunération supérieure pour ce que j'avais fait. Je me consolais néanmoins en me disant que de toutes façons, la liberté n'a pas de prix...

Note de l'auteur : au départ, j'étais parti sur tout à fait autre chose. Le revirement s'est fait suite à la lecture du billet "La Quadrature jette l'éponge". Il semblerait que nous prenions une route où mon histoire pourrait devenir possible (tout au moins le début, pour la fin j'en doute). Après DADVSI et HADOPI, il y maintenant LOPPSI et ACTA... Pour soutenir la Quadrature du Net, il vous est possible de faire un don si vous n'avez pas la possibilité de les aider autrement...

Créer votre première application CouchDB (Partie 4)

Nicolas Steinmetz — Wed, 06 Jan 2010 21:58:00 +0100

Pour ceux qui utiliserait le code mis dans les exemples, sachez qu'à partir de la version 0.10, le contenu du fichier lists/all.js qui s'écrivait :

function(head, row, req, info) {
  // !json templates.all
  // !code vendor/couchapp/path.js
  // !code vendor/couchapp/template.js
 
  return respondWith(req, {
    html : function() {
      if (head) {
        return template(templates.all.head, {
          assets : assetPath(),
        });
      } else if (row) {
        return template(templates.all.row, {
          fav: row.value,
        });
      } else {
        return template(templates.all.tail, {
            assets : assetPath(),
        });
      }
    },
  })
};

s'écrit désormais :

function(head, req) {
  // !json templates.all
  // !code vendor/couchapp/path.js
  // !code vendor/couchapp/date.js
  // !code vendor/couchapp/template.js
  // !json myfav
 
  provides("html", function() {
      
      send(template(templates.all.head, {
          assets : assetPath(),
          title : myfav.title,
       }));
      
      var row, key;
      while (row = getRow()) {
        key = row.key;
        var fav = row.value;
        send(template(templates.all.row, {
            url: fav.url,
            title: fav.title,
            description: fav.description,                      
        }));
      }
      
      return template(templates.all.tail, {
            assets : assetPath(),
      });
  });
};

et bien sur templates/all/row.html devient :

<dt><a href="<%= url %>"><%= title %></a></dt>
<dd><%= description %></dd>

Au passage, il m'a fallu récupérer la nouvelle version de vendor/couchapp/path.js.

Pour ceux que ça intéresse, le code est disponible ici : http://bitbucket.org/nsteinmetz/mycouchfav/.

Pour ceux qui veulent voir le rendu :

Show du document "couchdbkit" : http://nsteinmetz.cloudant.com:5984/mycouchfav/_design/mycouchfav/_show/fav/couchdbkit
List all favs : http://nsteinmetz.cloudant.com:5984/mycouchfav/_design/mycouchfav/_list/all/favs

Voilà, c'était histoire de me remotiver dans cette prise en main de CouchDB/CouchApp - peut-être que la prochaine fois, on verra un formulaire de soumission de favoris...

CouchDB 0.10.1 on Slackware 13.0

Nicolas Steinmetz — Sun, 03 Jan 2010 23:38:00 +0100

Dépendances de CouchDB

Dans un premier temps, il vous faut récupérer les slackbuilds suivants :

Les autres dépendances sont normalement satisfaites :

curl : à vérifier en utilisant un curl-config --version
make & gcc

Créer les packages des slackbuids (les slackbuils sont prévus pour i486 ; si vous êtes en 64 bits, éditer le fichier <package>.Slackbuild pour modifier la valeur de ARCH.

Pour que le SlackBuild fonctionne, il vous faut mettre l'archive des sources du package à créer dans le répertoire créé en décompressant le fichier slackbuild.

tar xzf js.tar.gz
cd js
./js.SlackBuild
=> Slackware package /tmp/js-1.8.0_rc1-x86_64-1_SBo.tgz created.
 
tar xzf icu4c.tar.gz
cd ../icu4c
./icu4c.SlackBuild
=> Slackware package /tmp/icu4c-4.2.1-x86_64-1_SBo.tgz created
 
tar xzf erlang-otp.tar.gz
cd erlang-otp
./erlang-otp.SlackBuild
=> Slackware package /tmp/erlang-otp-13B03-x86_64-1_SBo.tgz created.

Installer ensuite les packages créés :

nicolas@cassis:/tmp$ sudo installpkg icu4c-4.2.1-x86_64-1_SBo.tgz 
Verifying package icu4c-4.2.1-x86_64-1_SBo.tgz.                   
Installing package icu4c-4.2.1-x86_64-1_SBo.tgz:                  
PACKAGE DESCRIPTION:                                              
# icu4c (International Components for Unicode)                    
#                                                                 
# The International Components for Unicode (ICU) libraries provide
# robust and full-featured Unicode services on a wide variety of  
# platforms.                                                      
#                                                                 
# Homepage: http://www.icu-project.org/                           
#                                                                 
Executing install script for icu4c-4.2.1-x86_64-1_SBo.tgz.        
Package icu4c-4.2.1-x86_64-1_SBo.tgz installed.                   
 
nicolas@cassis:/tmp$ sudo installpkg js-1.8.0_rc1-x86_64-1_SBo.tgz
Verifying package js-1.8.0_rc1-x86_64-1_SBo.tgz.
Installing package js-1.8.0_rc1-x86_64-1_SBo.tgz:
PACKAGE DESCRIPTION:
# SpiderMonkey (Mozilla's JavaScript Engine)
#
# SpiderMonkey is the code-name for the Mozilla's C implementation of
# JavaScript. It can be used by applications such as elinks and others.
#
# This is the standalone version of the engine used by Firefox and other
# Mozilla applications.
#
# Homepage: http://www.mozilla.org/js/spidermonkey
#
Package js-1.8.0_rc1-x86_64-1_SBo.tgz installed.
 
nicolas@cassis:/tmp$ sudo installpkg erlang-otp-13B03-x86_64-1_SBo.tgz
Verifying package erlang-otp-13B03-x86_64-1_SBo.tgz.
Installing package erlang-otp-13B03-x86_64-1_SBo.tgz:
PACKAGE DESCRIPTION:
# Erlang (programming language)
#
# Erlang is a general-purpose concurrent programming language and
# runtime system.
# The sequential subset of Erlang is a functional language,
# with strict evaluation, single assignment, and dynamic typing.
# It was designed by Ericsson to support distributed,
# fault-tolerant, soft-real-time, non-stop applications.
#
# http://www.erlang.org/
#
Executing install script for erlang-otp-13B03-x86_64-1_SBo.tgz.
Package erlang-otp-13B03-x86_64-1_SBo.tgz installed.

Installation de CouchDB

Il vous faut au préalable créer un utilisateur et un groupe couchdb :

groupadd -g 231 couchdb
useradd -u 231 -g couchdb -d /var/lib/couchdb -s /bin/sh couchdb

Récupérer le slackbuild de CouchDB

il vous faut alors procéder de la façon suivante :

tar xzf couchdb.tar.gz
cd couchdb
# récupérer les sources de couchdb 0.10.1 et metter les dans votre répertoire couchdb
# éditer si besoin le SlackBuild
# créer votre package :
./couchdb.Slackbuild
=> Slackware package /tmp/SBo/couchdb-0.10.1-x86_64-1_SBo.tgz created.

Il ne reste plus qu'à installer le paquet :

installpkg /tmp/SBo/couchdb-0.10.1-x86_64-1_SBo.tgz

Démarrage / Arrêt automatique de CouchDB

Editer /etc/rc.d/rc.local pour y ajouter :

if [ -x /etc/rc.d/rc.couchdb ]; then
	. /etc/rc.d/rc.couchdb start
fi

et dans /etc/rc.d/rc.local_shutdown :

if [ -x /etc/rc.d/rc.couchdb ]; then
	. /etc/rc.d/rc.couchdb stop
fi

Ouvrez http://localhost:5984/_utils/

Et voilà... il est maintenant temps de vous relaxer

Edit 1 : Mise à jour suite à l'approbation & correction de mon slackbuild sur Slackbuilds.org

Perl vs Shell vs Python

Nicolas Steinmetz — Wed, 16 Dec 2009 23:00:00 +0100

Ayant suivi il y a 2 semaines une formation Perl de 3 jours vu qu'il s'agit d'un standard de fait chez JCDecaux pour tout ce qui touche au scripting, mon petit ressenti sur le sujet.

Tout d'abord, il faut dire que j'allais à cette formation avec un a priori plutôt négatif sur Perl de part ce que j'avais pu en entendre ici ou là. Il faut dire que j'ai plutôt été agréablement surpris par certains cotés.

Match perl vs bash :

Perl peut être vue comme une bonne alternative / un bon complément à des scripts bash. Plutôt que de vous casser la tête à apprendre à utiliser grep/sed/awk, vous pouvez faire la même chose mais uniquement en perl. Parce que bon, franchement awk, c'est peut être super puissant mais je trouve ça inabordable et loin d'être évident.
Je compte ainsi revoir certains scripts bash qui ne me satisfont pas pour voir si Perl ne me permettrait pas d'atteindre l'objectif souhaité.

Match perl vs python : avantage Python

Pour le coup, le langage avec des des $, %, et même @ devant les types de données, des accolades pour les débuts/fin de bloc qu'on ne sait jamais à quel niveau positionner pour rester lisible de bout en bout et des ; en fin de ligne, j'ai du mal. Surtout maintenant que je me suis habitué à la syntaxe python que je trouve infiniment plus lisible et moins source d'erreur.
Dans la même veine, les syntaxes sont pas des plus évidentes : ainsi dire que $tab est un scalaire, @tab un tableau, %tab un tableau associatif et que si on met un "antislash" devant on parle alors d'une référence vers le scalaire/tableau/tableau associatif, ça aide pas l'écriture d'un script

Par ex en perl :

if ( $toto == 2)
{
    print "Toto vaut : $toto\n";
}

et en python :

if toto == 2:
    print "Toto vaut %s" % toto

Perl fonctionne de façon beaucoup trop implicite/facultative contrairement à python. Python impose un certain nombre de conventions et c'est bien. Le "There is more than one way to do it" de Perl peut être séduisant mais aussi contre productif, surtout en entreprise.

Exemple pour parcourir un tableau en perl :

#! /usr/bin/perl -w
 
# Tableau simple
@tab = ("fraise", "abricot", "goyave", "pamplemousse");
foreach (@tab)
{
    print "Valeur : $_ \n";
}
 
# Tableau associatif
%hash = ("France" => "Paris", "Allemagne" => "Berlin", "Angleterre" => "Londres");
foreach (keys %hash)
{
    print "Pays : $_ , Capitale: $hash{$_}\n";
}

Le $_ est appelé scalaire par défaut. Il est conseillé de vivement l'utilisé plutôt que d'initialiser une variable. De prime abord, ça surprend. Il existe aussi un @_ dans les fonctions et qui correspond à un tableau d'arguments passés à la fonction.

Dans ce cas les parenthèses sont implicites. On peut bien sur écrire :

foreach(keys(%hash))

alors qu'en python :

tab = ["fraise", "abricot", "goyave", "pamplemousse"]
for fruit in tab:
    print "Valeur : %s" % fruit
 
hash = {'France' : 'Paris', 'Allemagne': 'Berlin',  'Angleterre' : 'Londres'};
for key, value in hash.items():
    print "Clé : %s Valeur %s" % (key, value)

Dans les deux cas, nous aurons :

Valeur : fraise
Valeur : abricot
Valeur : goyave
Valeur : pamplemousse
Pays : France , Capitale: Paris
Pays : Angleterre , Capitale: Londres
Pays : Allemagne , Capitale: Berlin

Si on rajoutait un tri en perl, en implicite cela peut aller jusqu'à :

foreach (sort keys %tab)
{
}

Difficile de s'y retrouver à mon humble avis.

Perl n'a pas de "prompt" intégré : Franchement pouvoir taper "python" dans un shell et ensuite codé en direct son script et le retoucher, que de temps gagné. Il y a certes perl -pe "commandes perl" mais c'est bien en deçà de ce que peut offrir python.
Mettre /usr/bin/perl -w en début de script permet de lever les warnings et corriger les éventuels bugs
Python propose le module "re" pour les expressions régulières. Pas besoin donc de se mettre spécifiquement à Perl s'il y a des besoins de RegExp
J'ai l'impression que la doc python est de meilleure qualité même si apparemment Perl rattrape petit à petit son chemin...
Globalement, Python et Perl doivent permettre de faire les mêmes choses, donc je vais considérer le périmètre des langages comme ex-aequo.
Même si cela m'a troublé de prime abord avec les listes en python, les listes en perl sont sympathiques :

@tab = ("un", "deux", "trois");
($t1, $t2, $t3) = @tab;
 print "t1 vaut $t1\n";
 print "t2 vaut $t2\n";
 print "t3 vaut $t3\n";

Contrairement à ce que l'on pourrait croire de prime abord, cela n'est pas un tableau mais juste un "panier" de variables. On peut donc utiliser $t1 & co.

La notation objet est plus claire en Python. Je n'adhère toujours pas au $titi->dosomething(); (comme en PHP en fait)
La prise en main de python est beaucoup plus immédiate (aux listes / tuples (grosso modo des listes non modifiables) / dictionnaires (tableaux associatifs) prêt )
- D'ailleurs, les listes en python correspondent aux tableaux en perl et les dictionnaires python au hash (tableau associatif) perl.
- Sauf erreur, il n'y a pas d'équivalent des tuples en perl
- Les listes en perl n'ont donc rien à avoir avec les listes en python (cela m'a pas mal dérangé durant la formation)

Ce qui fait qu'au final, je rejoins tout à fait David sur "Pourquoi Python & Django". A titre personnel, mon langage de prédilection va donc rester python et je vais voir dans quelle mesure je peux encourager python au boulot. J'y ai déjà glissé une appli Django après tout

Perl a malgré tout été une bonne surprise, je m'attendais à pire. Il convient par contre dans un contexte d'entreprise je pense de rendre le code le plus verbeux possible pour facilité sa reprise et sa maintenance.

Les exilés d'asceltis (Tome 1/2/3)

Nicolas Steinmetz — Wed, 16 Dec 2009 22:07:00 +0100

Pour rendre la pareille à la revue de BD de Jérome Renard, je vais vous parler des Exilés d'asceltis.

Ayant particulièrement aimé "Les Brumes d'Asceltis", j'ai naturellement suivi sur "Les exilés d'Asceltis" du même auteur Nicolas JARRY (qui au passage à écrit un roman génial : Chroniques du Loup de Deb, à lire également !).

Le synopsis est le suivant :

8000 ans avant les Brumes d’Asceltis, les Naabdirs furent chassés du continent par les Guerres Corgones. Ceux qui survécurent à l’exode trouvèrent refuge, puis prospérèrent dans l’Archipel fleuri d’Aloy Nihib. Sur Asceltis, Obion, le Dieu Naabdir agonise… Pour raviver la foi des siens, il leur envoie un messager, un bébé albinos. Mais les Naabdirs sont partagés: Comment interpréter la venue de cet enfant ? Faut-il revenir sur Asceltis ? Ou au contraire, rester sur l’Archipel ? Pour être certains de respecter la volonté de leur Dieu, ils décident d’attendre que l’enfant soit en âge de prendre lui-même cette délicate décision. Mais dans l’ombre, la présence de ce mystérieux bébé a déjà remis en route les sombres engrenages d’une implacable destinée…

L'histoire s'étale sur 3 tomes (et je ne pense pas qu'un 4ème arrive) ce qui fait qu'elle a le temps de se mettre en place, se développer et se finir sans tomber dans les séries à 40 épisodes où on gère mal sa fin comme Lanfeust des Etoiles par ex. Les dessins sont très beaux et le scénario se tient de bout en bout (avec un rythme assez continu, je n'ai pas observé de trous). Les personnages sont aussi bien réalisés, chacun apportant sa spécificité à l'édifice.

Pour ceux qui auraient lu les brumes d'Asceltis, ils peuvent éventuellement être un peu désemparés aux début car il n'y a pas vraiment de liens entre les deux séries (pas les mêmes races de personnages hormis les nains sur la fin et une autre race dont je ne retrouve pas le nom) et les dessins ne sont pas du tout les mêmes. Les exilés d'Asceltis sur une chronologie se place en fait bien avant les brumes d'Asceltis.

Bien sur, pour apprécier la série, il vous faut passer par le tome 1 car prendre l'histoire en route ne vous ménera nulle part.

Au final, ces deux séries se placent dans le haut de ma liste de BDs en terme de préférence. Il n'y a peut être que "Les naufragés d'Ythaq" (autre coup de coeur de l'année, j'y reviendrais prochainement) qui pourrait leur faire un peu d'ombre. Tout dépend comment cela va se terminer, en espérant qu'ils évitent l'écueil Lanfeust des Etoiles...

Faut-il sauver MySQL ?

Nicolas Steinmetz — Sun, 13 Dec 2009 17:41:00 +0100

A la demande de Jérome Renard et suite à la publication de "Help saving MySQL" par le fondateur de MySQL, ma première pensée fut ; "Hard to have an opinion on oracle/mysql debate. Was sun a better home ? FUD ?'

Sans nul doute il y a conflits d'intérêts entre Oracle & MySQL vu qu'il s'agit de deux bases de données relationelles; toutefois sur MySQL :

SI vous utilisez le moteur InnoDB, vous ^tes déjà dpendant d'Oracle depuis que ce dernier à racheter Innobase en octobre 2005. Votre dépendance cessera lorsque le nouveau plugin InnoDB sera sorti en version stable
La base de données Oracle est je pense principalement utilisée pour des applications orientées "entreprise". Dans ce contexte, pour Oracle, l'acquisition de MySQL peut lui permettre d'être sur de nouveaux segments comme le web ou les PME (qui ne peuvent s'offrir des licences Oracle).
En qui Sun était une meilleure maison pour MySQL ? J'ai plutôt l'impression que MySQL en a pati que tirer partie ?
Le fondateur de MySQL a déjà lancé l'Open Database Alliance ainsi qu'un fork de MySQL : Maria DB et une société de services Mpnthy AB. Quel est son intérêt dans l'histoire ? Est-ce si "désintéressé" que cela ?
La gestion du développement de MySQL était déjà sujet à critiques (toujours par le fondateur de MYSQL). En quoi cela peut être pire ?
Si Oracle venait à tuer MySQL (activement ou pas), il est toujours possible de forker (c'est d'ailleurs déjà fait) - donc hormis le coté médiatique / crédibilité / image de marque à gérer, où est le problème ?
MySQL s'est imposée comme base de données par défaut pour le web et PME. Ce serait certes une mauvaise image pour la promotion du libre de voir MySQL disparaitre. Mais comme dit précédemment, le fork peut se faire.
Pour les constructeurs de solutions opensource (ou pas) autour de MySQL, il leur faut évaluer leur dépendance vis à vis des composants retenus. Temps d'adopter un ORM ou d'être compatible multi-db ?
Pour éviter ce cas, n'aurait-il pas fallu créer une fondation MySQL, détentrice des droits et du contrôle sur son développement ? Cela pourrait être une porte de sortie pour Oracle... A vouloir monétiser MySQL, c'est peut être une leçon à retenir ?
(Edit1) La grand gagnant de MySQL vs Oracle sera-t-il Postgres ?
(Edit 2) Le MagIT indique d'ailleurs : "Notons que Monty Widenius n'est pas totalement désinteressé. Il a récement lancé Maria DB, un fork de MySQL et ambitionne de répliquer le succès qu'il a connu avec la première itération de sa base. Autant dire qu'un MySQL en bonne santé entre les griffres d'Oracle, pourrait largement éclipser ses chances de réussite".
(Edit 3) : Monty admet (fin d'article) que les développements autour de MySQL sont "morts" depuis 5 ans. Le rachat de MySQL par Sun n'a rien changé : Les innovations sur MySQL ont déjà été stoppées il y a 5 ans. Il s'agissait d'ailleurs d'un point sur lequel javais beaucoup d'espoirs en intégrant Sun. C'était un désastre complet en matière de développements. Et je comptais beaucoup sur Sun pour régler le problème. Malheureusement, cela ne s'est jamais produit. On peut donc dire que les développements sont déjà morts. C'est également pour cette raison que j'ai quitté le projet. D'ailleurs aujourd'hui, il y deux vrais forks (nouveaux projets dérivant du code initial de la base libre, NDLR) de MySQL, hors Drizzle.. Cela en fait de l'agitation poru un mort...
(Edit 4 du 05.01.10) : La communauté semble de plus en plus critique sur Monty par bien des aspets (cf billet du président de la fondation python). Plus j'y pense, plus je me dis que le danger de l'acquisition pour Monthy est de ne plus pouvoir profiter gratuitement du code de MySQL. Je m'explique, si on considère que MariaDB == MySQL + code spécifique, alors son entreprise dans son business plan prévoyait pour le moment de ne payer que les dev spécifiques. L'acquisition d'oracle peut mettre fin à ce modèle. D'où 2 solutons pour Monty : soit on reste dans la situation actuelle et il peut bénéficier du code de MySQL gratuitement pour faire ses affaires avec MariaDB. Soit il cherche à ce que les développeurs MySQL passent à MariaDB pour reproduire l'existant. Ainsi, le cout logiciel de MariaDB reste le code spécifique et non la globalité du code (MySQL + code spécifique).
(Edit 5 du 06/01/10) :Monty Widenius wants another billion dollars, should we help him ?. Tout est dit sur Monty...

Sans vouloir voir MySQL disparaitre, j'ai plutôt l'impression que les problèmes étaient déjà présents par le passé et que l'acquisition d'Oracle ne fait que les mettre en valeur / compléter.

Votre avis ?

Clément

Nicolas Steinmetz — Fri, 13 Nov 2009 00:17:00 +0100

2 ans, 8 mois et 20 minutes après Hugo, voici Clément (4.4 kg, 54.5 cm) :

Toute la famille se porte bien.

Les vues DNS pour fluidifier la gestion de vos applications

Nicolas Steinmetz — Fri, 06 Nov 2009 00:18:00 +0100

Contexte / Objectifs

Imaginer :

Vous êtes dans un grosse PME multi-sites ou avec un hébergement multi-sites
Un applicatif est soit réparti sur chaque site, soit il est porté globalement en multi-site (ex un serveur de mail, une application web, etc)
Votre but est de minimiser la gestion de ces équipements tout en gardant une homogénéité au niveau de la conf (tout le monde utilise par ex mail.maboite.tld pour accéder au webmail mais cela pointe en fait sur chaque serveur de mail local).

Deux modes de gestion :

Au niveau de chaque site, vous avez la solution de déployer un serveur DNS qui gère les entrées correspondantes et faire ainsi la gestion de N dns lors de la modification d'une entrée.
Vous utilisez les vues DNS et vous déployez un serveur maitre et les vues se transmettront aux esclaves par simple transfert de zone.

Mais au fait, c'est quoi une vue DNS ???

Kezako une vue DNS ?

Pour un serveur DNS donné, celui-ci peut répondre des informations différentes suivant le client ou bien l'IP du serveur DNS utilisée pour faire sa requête.

Dans le cas de mon webmail :

Suppsons que la répartition entre le site A et le site B se fasse par round robin
le client arrive sur un Reverse Proxy (RP) qui le dispatche ensuite parmi plusieurs frontaux
Quand un client arrive sur le site A, le RP doit renvoyer sur les frontaux 10.8.0.102 à 10.8.0.104
Quand un client arrive sur le site B, le RP doit renvoyer sur les frontaux 10.9.0.102 à 10.9.0.104

Construisons une petite matrice de flux :

	Vue Site A	Vue Site B
Frontaux Site A	X
Frontaux Site B		X
RP Site A	X
RP Site B		X
Transfert de zone	X	X

Equipements

Soit 5 serveurs ayant les rôles suivants :

srv101 / 10.8.0.1 : RP + DNS Master site A
srv102 / 10.8.0.102 : Serveur Mail Site A 1
srv103 / 10.8.0.103 : Serveur Mail Site A 2
srv104 / 10.8.0.104 : Serveur Mail Site A 3
srv201 / 10.9.0.1 - 10.9.0.2 : RP + DNS Slave site B
srv202 / 10.9.0.102 : Serveur Mail Site B 1
srv203 / 10.9.0.103 : Serveur Mail Site B 2
srv204 / 10.9.0.104 : Serveur Mail Site B 3

Mise en place de la configuration DNS

Note

Le DNS ne doit plus écouter sur le port local
Il ne doit pas y avoir de règle sur localhost
- Si localhost autorisé, alors localhost == 127.0.0.1 == IP1.DU.SERVEUR.FQDN == IP2.DU.SERVEUR.FQDN == ... => /etc/resolv.conf à renseigner avec l'IP locale sur lequel le serveur DNS écoute.
Pour permettre le transfert de zone, le DNS slave doit se synchroniser avec le serveur maitre en faisant des requêtes sur 2 ip distinctes pour voir les 2 vues :
- Si le DNS slave interroge le DNS maitre avec son IP principale (10.9.0.1), alors il obtient la vue du site B
- Si le DNS slave interroge le DNS maitre avec son IP secondaire (10.9.0.2), alors il obtient la vue du site A
Mise en place du transfert sur le DNS slave :
- Installer Bind
- Mettre en place le fichier named.conf
- Lancez bind, il récupère alors les fichiers de zone automatiquement du serveur maitre

Conf DNS Master

Contenu de /etc/named.conf

acl "trusted" {
 localhost;
 10.0.0.0/8;
};
 
options {
    directory "/var/named";
    listen-on {
        10.8.0.1;
    };
    auth-nxdomain no;
    allow-query { trusted; };
    allow-recursion { trusted; };
};
 
# Define ACL for views
acl "frontaux_siteb" {
    10.9.0.102;
    10.9.0.103;
    10.9.0.104;
};

acl "frontaux_sitea" {
    10.8.0.102;
    10.8.0.103;
    10.8.0.104;
};
 
 acl "rpdns_sitea" {
    10.8.0.1; 
};
 
acl "rpdns_siteb" {
    10.9.0.1;
};

acl "rpdns_siteb_ext" {
    10.9.0.2;
};

 # Views definitions
view "site_a" {
	match-clients { frontaux_sitea; rpdns_sitea; };

	# Vue locale
	zone "domaine.tld" IN {
		type master;
		file "sitea.domaine.tld.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.2; };
		notify yes;
	}; 
};
 
view "dns_slave" {
	match-clients { rpdns_siteb_ext; };
 
	# Vue locale
 	zone "domain.tld" IN {
		type master;
 		file "siteb.domaine.tld.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.2; };
		notify yes;
	}; 
};
 
view "site_b" {
	match-clients { frontaux_siteb; rpdns_siteb; };
 
	# Vue locale
	zone "cyclo.priv" IN {
		type master;
 		file "pla.cyclo.priv.zone";
		allow-update { none; };
		allow-transfer { 10.9.0.1; };
		notify yes;
	}; 
};

Conf DNS Slave

acl "trusted" {
 localhost;
 10.0.0.0/8;
};
 
options {
    directory "/var/named";
    listen-on {
        10.8.0.1;
    };
    auth-nxdomain no;
    allow-query { trusted; };
    allow-recursion { trusted; };
};
 
# Define ACL for views
acl "frontaux_siteb" {
    10.9.0.102;
    10.9.0.103;
    10.9.0.104;
};

acl "frontaux_sitea" {
    10.8.0.102;
    10.8.0.103;
    10.8.0.104;
};
 
 acl "rpdns_sitea" {
    10.8.0.1; 
};
 
acl "rpdns_siteb" {
    10.9.0.1;
};

acl "rpdns_siteb_ext" {
    10.9.0.2;
};

# Views definitions
view "site_a" {
	match-clients { frontaux_sitea; rpdns_sitea; };

	# Vue locale
	zone "domaine.tld" IN {
		type slave;
		file "sitea.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.2;
	}; 
};
 
view "dns_slave" {
	match-clients { rpdns_siteb_ext; };
 
	# Vue locale
 	zone "domain.tld" IN {
		type slave;
 		file "sitea.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.1;
	}; 
};
 
view "site_b" {
	match-clients { frontaux_siteb; rpdns_siteb; };
 
	# Vue locale
	zone "cyclo.priv" IN {
		type slave;
 		file "siteb.domaine.tld.zone";
		masters { 10.8.0.1; };
		transfer-source 10.9.0.1;
	}; 
};

Conf Zone sitea.domaine.tld.zone

$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
        2009100101
        3600
        3600
        3600
        3600 )
@           IN      NS      domaine.tld.
dns     	IN      A       10.8.0.1
www2		IN      A       10.8.0.102
www2		IN      A       10.8.0.103
www2		IN      A       10.8.0.104
webmail 	IN		CNAME	www2

Conf Zone siteb.domaine.tld.zone

$TTL 864000
domaine.tld. IN SOA dns.domaine.tld. root.domaine.tld. (
        2009100101
        3600
        3600
        3600
        3600 )
@           IN      NS      domaine.tld.
dns     	IN      A       10.8.0.1
www2		IN      A       10.9.0.102
www2		IN      A       10.9.0.103
www2		IN      A       10.9.0.104
webmail 	IN		CNAME	www2

Conf OS

/etc/resolv.conf

Serveurs du site A :

search domaine.tld
nameserver 10.8.0.1

Serveurs du site B :

search domaine.tld
nameserver 10.9.0.1

Tests

Depuis le site A

La commande dig @10.8.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.8.0.x

Depuis le site B

La commande dig @10.9.0.1 webmail.domain.tld depuis un serveur du site A doit vous renvoyer une réponse en 10.9.0.x

Transfer de zone

Lorsque vous démarrez le DNS esclave, il doit récupérer automatiquement les deux fichiers de zone avec un contenu identique à celui décrit plus haut.

Sources

Pour conclure...

J'espère que c'est pas trop confus et que cela vous aura donner des idées.

Dans mon cas, j'utilise ça avec en plus une zone privée :

les internautes arrivent de l'extérieur avec une url publique
ils transitent sur le réseau interne via des urls privées

mod_wsgi 2.6 pour slackware 13.0 x86_64 et 12.x

Nicolas Steinmetz — Wed, 21 Oct 2009 23:29:00 +0200

Décidément, je vais finir par packager mod_wsgi pour toutes les distributions : après Arch il y a de ça quelques temps, voici le package Slackware.

Restons modeste, il ne s'agit que d'une mise à jour mineure du slackbuild existant pour passer de la version 2.0 à 2.6.

Une fois récupéré :

installpkg mod_wsgi-2.6-x86_64-1_nst.tgz

Ensuite dans /etc/httpd.conf, il vous suffit de rajouter une ligne du type :

Include /etc/httpd/mod_wsgi.conf

Puis de redémarrer apache :

/etc/rc.d/rc.httpd reload

Pour Slackware 12.2 :

Par contre, il vous faut créer le fichier /etc/httpd/mod_wsgi.conf :

LoadModule wsgi_module lib/httpd/modules/mod_wsgi.so

Django : limit_choices_to pour présenter un sous-ensemble des données d'un modèle

Nicolas Steinmetz — Tue, 29 Sep 2009 09:54:00 +0200

Dans le cadre des relations "One to many" ou "Many to Many", il est possible de présenter un sous-ensemble de votre modèle en fonction de critères de tri.

Codant une application de gestion de reverse proxys pour les sites web Vélos en libre service, il me faut gérer différents types d'url (une url publique, une url pour les abonnements, une url d'admin, les déclinaisons linguistiques et autres alias en tous genre) et ce pour chaque type d'environnement (VABF, PREPROD, PROD). J'aurais pu créer autant de modèles que j'ai de type d'url mais cela aurait été particulièrement contre-productif. J'ai donc un modèle unique avec les paramètres "type d'url" et "environnement". Dès lors, quand je définis les urls d'une ville, il me suffit de faire des relations "One to Many" ou "Many to many" vers mon objet Url.

Cela donne grosso modo la chose suivante pour l'objet Url:

class Url(models.Model):
    """
    Url description
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    URL_CHOICES = (
        ('1', 'www'),
        ('2', 'subscription'),
        ('3', 'admin'),
        ('4', 'secondary'),
        ('5', 'translation'),        
    )
    name = models.CharField("DNS", help_text="Provide url of the site without http(s)://", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the url", blank=True, max_length=100)
    url = models.URLField("URL", help_text="Provide url of the site *with* http(s)://", verify_exists=False)
    urltype = models.CharField("URL Type", help_text="What kind of url it is ?", max_length=20, choices=URL_CHOICES)
    envt = models.CharField("Environement", help_text="In which environment is used this url ?", max_length=100, choices=ENVT_CHOICES)
    
    def __unicode__(self):
        return self.name

Dans un premier temps, la classe Town est assez simple à monter :

class Town(models.Model):
    """
    Town
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    STATE_CHOICES = (
        ('1', 'On construction'),
        ('2', 'On maintenance'),
        ('3', 'Open'),
        ('4', 'Closed'),
    )
    name = models.CharField(help_text="Provide the name of the town", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the town", blank=True, max_length=100)
    prod_status = models.CharField("PROD status", help_text="State of the site on PROD environment", max_length=20, choices=STATE_CHOICES)
    prod_www = models.ForeignKey(Url, verbose_name="WWW Public URL", help_text="Public url of the site like www.velib.paris.fr", related_name="prod_www")
    prod_abo = models.ForeignKey(Url, verbose_name="Subscription URL", help_text="HTTPS URL used for all sensible process like subscribption, my account, etc. Is often like https://abo-<town>.cyclocity.fr", related_name="prod_abo",)
    prod_admin = models.ManyToManyField(Url, verbose_name="Internal administration URL(s)", help_text="URL used to access back-office", related_name="prod_admin") 
    prod_other = models.ManyToManyField(Url, verbose_name="Other URL(s)", help_text="Other urls related to the site like aliases related to the public url", related_name="prod_other", blank=True)
    prod_translation = models.ManyToManyField(Url, verbose_name="Translations URL", help_text="If site has translated versions, their public urls are listed here" ,related_name="prod_translation", blank=True)

Cette modélisation, bien que remplissant le besoin a un désavantage certain : tous les objets de type Url sont présentés. Si on part sur 17 villes * 3 environnements * 3 urls "publiques" à minima, soit pas moins de 153 urls disponibles. Pas simple de s'y retrouver (et encore je vous dis pas tout, il y en a bien plus en fait )

Il faut alors être en mesure pour l'attribut prod_www de ne présenter que les urls de type "www" et pour l'environnement "prod".

Cela est possible très simplement grâce au filtre limit_choices_to qui adopte la syntaxe suivante :

class Example(models.Model):
    foo = models.ForeignKey(<Modèle>, limit_choices_to = {'<attribut du modèle en question>': "<valeur>"}

Ce qui dans mon cas donne pour filtrer sur le type d'url et l'environnement :

class Town(models.Model):
    """
    Town
    """
    ENVT_CHOICES = (
        ('1', 'VABF'),
        ('2', 'PREPROD'),
        ('3', 'PROD'),
    )
    STATE_CHOICES = (
        ('1', 'On construction'),
        ('2', 'On maintenance'),
        ('3', 'Open'),
        ('4', 'Closed'),
    )
    name = models.CharField(help_text="Provide the name of the town", max_length=100)
    description = models.CharField(help_text="You can provide extra information on the town", blank=True, max_length=100)
    prod_status = models.CharField("PROD status", help_text="State of the site on PROD environment", max_length=20, choices=STATE_CHOICES)
    prod_www = models.ForeignKey(Url, verbose_name="WWW Public URL", help_text="Public url of the site like www.velib.paris.fr", related_name="prod_www", limit_choices_to = {'urltype': 1, 'envt': 3})
    prod_abo = models.ForeignKey(Url, verbose_name="Subscription URL", help_text="HTTPS URL used for all sensible process like subscribption, my account, etc. Is often like https://abo-<town>.cyclocity.fr", related_name="prod_abo", limit_choices_to = {'urltype': 2, 'envt': 3})
    prod_admin = models.ManyToManyField(Url, verbose_name="Internal administration URL(s)", help_text="URL used to access back-office", related_name="prod_admin", limit_choices_to = {'urltype': 3, 'envt': 3} ) 
    prod_other = models.ManyToManyField(Url, verbose_name="Other URL(s)", help_text="Other urls related to the site like aliases related to the public url", related_name="prod_other", limit_choices_to = {'urltype': 4, 'envt': 3}, blank=True)
    prod_translation = models.ManyToManyField(Url, verbose_name="Translations URL", help_text="If site has translated versions, their public urls are listed here" ,related_name="prod_translation", limit_choices_to = {'urltype': 5, 'envt': 3}, blank=True)

Comme le montre l'exemple de la documentation, ce filtre marche aussi de façon dynamique ou bien avec des objets Q pour les requêtes complexes :

limit_choices_to = {'pub_date__lte': datetime.now}

Du coup, le formulaire de création/édition d'une ville ne me présente plus qu'un nombre réduit d'urls pour un champ donné. Au pire, ma liste de choix aura un maximum d'éléments correspondant au nombre de villes déjà entrées dans le système. Il me faudrait affiner le filtre pour en plus ne présenter que les urls non déjà liées à une autre ville. Mais c'est moins évident et immédiat

En espérant que cela puisse être utile à d'autres...

Installer Slackware 13.0 sur une clé USB pour utilisation dans un linutop

Nicolas Steinmetz — Sat, 26 Sep 2009 00:26:00 +0200

Si comme moi, vous avez un linutop et que vous souhaitez y mettre en place une slackware plutôt que la version Linutop (basée sur Xubuntu), voici la marche à suivre.

Depuis un autre ordinateur, faire une installation classique de Slackware sur votre clé USB

Dans mon cas, cela donne :

/dev/sda1    swap     1G
/dev/sda2    ext4     8G

A ce stade, dans mon cas, la clé refuse de démarrer. Même en créer la clé usb de démarrage, pas mieux car les modules USB sont chargés après qu'il chercheà accéder aux données de la partition /

Une fois l'installation finie, redemarrer votre ordinateur en laissant le CD de Slackware pour qu'il se lance automatiquement. Au lieu de taper setup pour lancer l'installateur Slackware, procéder de la façon suivante.

Mise en place du chroot

mount /dev/sda1 /mnt
swapon /dev/sda2
mount -o bind /proc /mnt/proc
chroot /mnt /bin/bash

Récupérer la version du noyau :

Via un uname -r :

uname -r
2.6.29.6-smp

Création d'un initrd personnalisé

Le but ici est de rajouter les modules permettant de booter sur une clé USB et en ext4 ; se reporter à /boot/README.initrd pour plus d'info.

mkinitrd -c -k 2.6.29.6-smp -m usbcore:ehci-hcd:uhci-hcd:ohci-hcd:usb-storage:ext4 -f ext4 -r /dev/sda2

A adapter bien sur à vos besoins.

Ensuite modifier le fichier /boot/initrd-tree/init :

Trouvez la ligne # Initialize LVM: et au dessus, ajoutez les 2 lignes suivantes :

echo "Sleeping to allow USB Init."
sleep 10

Regénérez l'initrd en tapant mkinitrd sans arguments.

Mise à jour de Lilo

Modifier /etc/lilo.conf pour ajouter la ligne initrd = /boot/initrd.gz :

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
  initrd = /boot/initrd.gz
# Linux bootable partition config ends

Faites un test de chargement des paramètres de lilo :

lilo -t -v

Si pas d'erreurs (il se peut qu'il y ait des warnings par contre), appliquez les nouveaux paramètres :

lilo -v

Sortez de votre chroot via un exit, démontez vos périphériques :

swapff /dev/sda1
umount /mnt

Redémarrez votre ordinateur via un reboot.

Mettre la clé dans le linutop et apprécier

Source et autres méthodes (non testées) : Guide - Installing Slack 12.0 To a USB Drive

Mon comparatif Django vs Symfony

Nicolas Steinmetz — Mon, 03 Aug 2009 14:31:00 +0200

Dans la mesure où au boulot les applications symfony commencent à se multiplier (on va passer de 1 à 2, restons modestes ) et que je songeais par ailleurs à recoder une appli existante en symfony pour des raisons de compétences internes à JCDecaux (Python/Django, c'est pas gagné a priori...), je me suis décidé à me (re)plonger dans Symfony.

Après quelques heures de lectures et fait le tutoriel en une heure et surtout le tutoriel Jobeet, voici ce que j'en retire par rapport à mon expérience sur Django. (pour être tout à fait honnête, j'ai consciencieusement suivi le tutoriel jusqu'à la fin du jour 7 - après, j'ai lu avec attention mais pas recopié les bouts de code).

Cela n'engage bien sur que moi, je suis ouvert à toute discussion constructive et cela ne se veut pas être un nid à troll N'ayant pas non plus lu toute la documentation Symfony, je peux dire des âneries ou des choses fausses car non présentées dans les documents que j'ai pu lire.

Sur les modèles :

Relations OneToOne, OneToMany ou ManyToMany : avantage Django puisque beaucoup plus limpide et pas besoin de déclarer les tables intermédiaires pour les relations ManyToMany. A contrario, cela peut paraître trop magique
Type de modèle : avantage Django. Symfony reste sur les types "de base" et il faut donc appeler ensuite un validateur pour valider le contenu d'un champ. Avec Django, c'est du tout en un par ex : models.UrlField qui ne stocke qu'une url et vérifie si elle est valide (et éventuellement si elle existe bien)

Routing :

Avantage Symfony sur les "Route Collection Class" : en gros en déclarant une fois par ex SfDoctrineCollectionRoute, cela vous met automatiquement les 7 méthodes à disposition (de base, new, create, edit, update, delete, show). Dans django, à ma connaissance, cela n'existe pas.
~~Avantage Django sur la flexibilité des urls (mais en est-ce vraiment un). On peut sortir du /module/action/param de Symfony.~~ Ex-aequo sur la capacité à créer son schema d'url (merci Niko pour la correction)
Définition des routes : Avantage Symfony - les possibilités ont l'air plus fines (limité une route à une méthode par ex) et plus lisibles à mettre en oeuvre (les regexps des routes Django sont pas les plus simples à mon sens). Par contre, c'est sur que les routes Django sont du coup moins verbeuses que celle de Symfony (là encore, ça se discute)
Les urls par défaut fonctionnent de base sous Symfony. Le /module/action a pour avantage de pouvoir jouer tout de suite avec Symfony. Sous Django, cela n'est pas possible de sauter la case urls.py.

Fixtures :

Sous Symfony, il est intéressant de voir que l'on peut faire une boucle "for" pour insérer des fixtures en masse

Formulaires :

Symfony s'inspirant officiellement de django.forms, je ne reviendrais pas là dessus.

Templating :

Même si PHP peut être vu comme un langage de template en tant que tel, je suis plutôt adepte de l'approche de django.
Avantage Symfony sur les "partials". Je ne vois pas trop l'équivalent sous django de prime abord. C'est autre chose que l'héritage de template...
Avantage Symfony sur la gestion des "flash" (inspiré de Rails de mémoire). N'existe pas à ma connaissance sous Django.

Tests :

Pas de comparatif, je n'ai pas pris le temps de regarder ceux de django (aie, pas taper...)
En me basant sur la lecture j'ai l'impression que les tests de Symfony vont plus loin (tests unitaites + fonctionnels)

Authentification/Authorisation/Cache :

Ex-aequo ?

Gestion des "settings" :

Avantage Symfony (sous réserve d'aimer YAML) vu qu'il est possible de renseigner un fichier <module>/config/app.yml par ex. Ca évite de polluer le settings.py ou d'oublier des settings sur votre machine de dev lors d'un déploiement en prod.
Avantage Symfony sur la gestion des environnements sur le principe. Après tout dépend comment se fait le déploiement et qui le gère... (par ex, je ne donne pas les identifiants de prod aux équipes de dev au bureau...)

Interface d'admin :

Avantage Django je trouve, même si le fait qu'il faille maintenant toucher à admin.py rend l'accès à l'interface un peu plus fastidieux.
Le chevauchement de l'admin Symfony entre les données et le formulaire de tri sous Safari sur mon macbook n'aide pas non plus...

PHP / Python :

Même si j'arrive à lire la syntaxe PHP (que de progrès...), je trouve celle de python beaucoup plus agréable à lire et les $this-> et les foo::bar me laissent toujours perplexe
J'ai l'impression (donc totalement subjectif) que pour un résultat égal, il y aurait bcp plus de lignes dans un projet Symfony que Django

Plugins vs Applications redistribuables :

Dans django, tout est application et il est assez aisé de les redistribuer. Sous Symfony, cela prend le nom de plugins et je pense au final que c'est assez équivalent.
Symfony a un gros avantage, c'est que les plugins sont officiellement référencés. Pour django, faut passer par la case Google ou chercher dans les entrailes de github, bitbucket, google-code.

Globalement :

J'ai l'impression que Python/Django est de plus haut niveau (dans le sens macro/micro et non qualitatif) que PHP/Symfony. Je rajoute volontairement le langage car je me demande si ça ne vient pas également du langage et non uniquement du mode d'implémentation du framework. A l'inverse, on a peut être un niveau de granularité plus fin avec Symfony ?
J'ai une impression de "trop de fichiers" dans Symfony et de me noyer un peu dans cet ensemble.
Le tutoriel en une heure qui n'existe pas en version doctrine, c'est un peu dommage lorsqu'on veut partir sur Doctrine dès le départ
La double doc en version doctrine / propel est peut être source de confusion
Django et Symfony ont tous les deux une doc de qualité, même si parfois je m'y perds un peu (l'une comme l'autre).
Symfony est dans une logique beaucoup plus stricte au niveau MVC quand Django fait du MVT (Modèle Vue Template)

Pour bien faire, il faudrait faire un jobeet en version Django pour se faire une véritable idée sur les 2 frameworks. Pas sur d'avoir envie de faire ça dans l'immédiat par contre...

Personnellement :

J'y vois plus clair sur Symfony et c'était le but de l'exercice
je pense aller titiller un peu l'équipe de dev sur quelques points en particulier à mon retour de congés
Pour coder à titre perso, je vais rester sur Django

Au plaisir d'échanger avec vous maintenant (pour les qqs uns qui ne seraient pas en vacances)

Couchapp : créer votre première application CouchDB (Partie 3)

Nicolas Steinmetz — Fri, 10 Jul 2009 23:16:00 +0200

Devant la "foule" de commentaires (hum), je continue (tout seul) mon épopée dans les méandres de CouchDB.

Dans les points non traités la dernière fois, nous allons voir ce jour :

Voir comment on peut remplacer le "My favs ... " dans head.html par une variable extérieure au template (facile - déjà fait mais cela rajoutait une grande quantité d"infos à ce post déjà très long je pense...),
Mieux comprendre les "!json" et "!code".

Externaliser le "My favs ..."

Commençons par créer un fichier "myfav.json" à la racine du projet contenant, qui contiendra une valeur qui sera utilisé dans la balise title et en tête de page du site :

{
   "title": "My favs - All my bookmarks."
}

Ensuite dans "list/all.js", nous avons deux actions à mener :

Faire en sorte que ce fichier soit lu lors de la création de la liste, afin de récupérer la valeur de "title",
Mettre à la disposition du template la valeur title contenu dans myfav.json.

Ce qui nous donne :

function(head, row, req, info) {
  // !json templates.all
  // !code vendor/couchapp/path.js
  // !code vendor/couchapp/template.js
  // !json myfav
 
  return respondWith(req, {
    html : function() {
      if (head) {
        return template(templates.all.head, {
          assets : assetPath(),
          title : myfav.title,
        });
      } else if (row) {
        return template(templates.all.row, {
          fav: row.value,          
        });
      } else {
        return template(templates.all.tail, {
            assets : assetPath(),
        });
      }
    },
  })
};

Dans la mesure où je ne veux faire apparaître la valeur de "title" que pour la balise <title></title> et en tête de page, je n'ai besoin de le fournir que pour le template head.

D'ailleurs le fichier templates/all/head.html devient :

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="../../style/main.css" type="text/css"/>
    <title><%= title %></title>
  </head>
  <body>
    <div id="header">
        <h1><%= title %></h1>
    </div>
    <div id="content">
      <h2>Recently...</h2>
      <dl>

Si vous rajoutez par ex <%= title %> dans templates/all/row.html en pensant que la valeur sera renseignez et bien vous vous trompez et provoquerez une jolie erreur au niveau de CouchDB.

Faites un push de votre application et rendez-vous ensuite sur http://localhost:5984/myfav/_design/mycouchfav/_list/all/favs/ pour apprécier le résultat.

Dans la même veine, il vous reste à modifier "shows/fav.js" et "templates/fav.html" ; par contre, utilisant déjà la variable title pour le titre du favori, j'utilise à la place la variable site_title :

function(doc, req) {  
  // !json templates.fav
  // !code vendor/couchapp/template.js
  // !code vendor/couchapp/path.js
  // !json myfav
 
  // we only show html
  return template(templates.fav, {
    title : doc.title,
    url : doc.url,
    description : doc.description,
    assets : assetPath(),
    site_title : myfav.title,
  });
}

<!DOCTYPE html>
<html>
  <head>
    <title><%= title %> - <%= site_title %></title>
    <link rel="stylesheet" href="../../style/main.css" type="text/css">
  </head>
  <body>
    <div id="header">
        <h1><%= site_title %></h1>
    </div>
    <div id="content">
      <h2><a href="<%= url %>"><%= title %></a></h2>
        <div class="body"><%= description %></div>
    </div>    
  </body>
  <script src="/_utils/script/json2.js"></script>
  <script src="/_utils/script/jquery.js?1.2.6"></script>
  <script src="/_utils/script/jquery.couch.js"></script>
  <script src="<%= assets %>/vendor/couchapp/jquery.couchapp.js"></script>
</html>

Faites un push de votre application et rendez-vous ensuite sur http://localhost:5984/myfav/_design/mycouchfav/_show/fav/couchdbkit pour apprécier le résultat.

Mieux comprendre "!json" et "!code"

Grosso modo, !code et !json ont la même objectif : insérer des données dans votre vue. La différence tient dans le fait que !code injecte du code alors que !json injecte des données ou des fichiers (en utilisant par ex !json _attachments/file.ext).

De même, attention lors de vos inclusions : dans le cas d'une arboresence, si vous appelez un élément de premier niveau, alors tous ses sous-niveaux seront inclus. L'écriture suivante est donc redondante :

function(doc) {
  // !json lib
  // !json lib.templates.post
}

Pour plus d'info, voir la fin de cette page.

Voilà pour aujourd'hui, suite au prochain épisode...

Couchapp : créer votre première application CouchDB (Partie 2)

Nicolas Steinmetz — Fri, 03 Jul 2009 00:04:00 +0200

La dernière fois, je vous ai laissé avec pas grand chose, à savoir couchapp installé et une squelette d'application.

Aujourd'hui, nous allons être nettement plus ambitieux en prenant comme prétexte une application de gestion de favoris (à la delicious, en mode mono-utilisateur). Nous allons aborder le rendu d'un document en tant que tel (aka "show") et les listes de documents (aka "list").

Avant toute chose... couchapp !

Générons notre petite application :

couchapp-cloned	mycouchapp
tetram:CouchDB nicolas$ couchapp generate mycouchfav
[INFO] Generating a new CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchfav

Et poussons notre application dans notre instance CouchDB (que vous avez démarré par ailleurs) :

tetram:CouchDB nicolas$ cd mycouchfav/
tetram:mycouchfav nicolas$ couchapp push myfav
[INFO] Pushing CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchfav to design doc:
http://127.0.0.1:5984/myfav/_design/mycouchfav
[INFO] Visit your CouchApp here:
http://127.0.0.1:5984/myfav/_design/mycouchfav/index.html

Vinrent ensuite les documents

Commençons par nous créer trois favoris depuis Futon ( http://localhost:5984/_utils/) avec la structure suivante :

title
url
description
tag

Ci-après mon jeu d'exemple au format json :

{
   "_id": "couchdb",
   "title": "CouchDB Official site",
   "url": "http://couchdb.apache.org/",
   "description": "Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API",
   "tag": [
       "couchdb",
       "database",
       "document"
   ]
}
 
{
   "_id": "couchdbkit",
   "title": "Couchdbkit",
   "description": "Couchdbkit goal is to provide a framework for your Python application to access and manage Couchdb.",
   "url": "http://www.couchdbkit.org/",
   "tag": [
       "couchdb",
       "python",
       "framework"
   ]
}
 
{
   "_id": "couchapp",
   "title": "couchapp",
   "description": "Utilities to make standalone CouchDB application development simple",
   "url": "http://github.com/couchapp/couchapp/tree/master",
   "tag": [
       "couchdb",
       "python",
       "ruby"
   ]
}

Tu me le montres ton document ?

L'url pour accéder à un document est du type :

http://localhost:5984/<nom_de_la_db>/_design/<nom_du_design>/_show/<nom_du_show>/<id_du_document>

Dans notre cas, par ex : http://localhost:5984/myfav/_design/mycouchfav/_show/fav/couchdbkit (si je prends le favori ayant pour id "couchdbkit".

Vous venez de déduire que mon "show" se nomme "fav". Plus exactement, il s'agit du fichier show/fav.js avec le contenu suivant :

function(doc, req) {  
    // !json templates.fav
    // !code vendor/couchapp/template.js
    // !code vendor/couchapp/path.js
 
    return template(templates.fav, {
        title : doc.title,
        url : doc.url,
        description : doc.description,
        assets : assetPath(),
       }
    );
}

Expliquons ce qu'il contient :

Pour un show, la fonction js prend 2 arguments : doc et req ; ce dernier content la requête et va trouver le document associée à cette requête.
On initialise une variable json, qui est utilisée ensuite pour appelé le template templates/fav.html
On inclut ensuite 2 fichiers js fournis par couchapp
Le return indique que l'on va charger le fichier templates/fav.html avec 4 variables qui sont le titre (title), l'url, la description du favori, ainsi qu'une variable assets qui permet de renseigner un chemin vers différents fichiers (css, js, etc).

Il nous resque plus qu'à construire le fichier templates/fav.html :

<!DOCTYPE html>
<html>
    <head> 
        <title><%= title %></title>
    </head>
    <body>
    <div id="header"></div>
    <div id="content">
        <h1><a href="<%= url %>"><%= title %></a></h1>
        <div class="body"><%= description %></div>
    </div>    
</body>
<script src="/_utils/script/json2.js"></script>
<script src="/_utils/script/jquery.js?1.2.6"></script>
<script src="/_utils/script/jquery.couch.js"></script>
<script src="<%= assets %>/vendor/couchapp/jquery.couchapp.js"></script>
</html>

Il ne nous reste plus qu'à .... et non pas visualiser votre page mais au préalable pousser vos fichiers dans votre instance CouchDB :

tetram:mycouchfav nicolas$ couchapp push myfav
[INFO] Pushing CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchfav to design doc:
http://127.0.0.1:5984/myfav/_design/mycouchfav
[INFO] Visit your CouchApp here:
http://127.0.0.1:5984/myfav/_design/mycouchfav/index.html

Maintenant, ouvrez votre navigateur sur l'url http://localhost:5984/myfav/_design/mycouchfav/_show/fav/couchdbkit et vous retrouvez le contenu très sommairement présenté de votre favori avec son titre, son url et sa description.

En conclusion, pour afficher un document, il nous faut :

Un template (ici : templates/fav.html)
Une fonction en javascript qui nous permet de manipuler les attributs du documents en vue de leur rendu. La fonction est de type function(doc,req). La fonction est située dans un fichier shows/nom_du_show.js (ici shows/fav.js)
Ne pas oublier de faire un "couchapp push" pour envoyer vos fichiers dans votre instance CouchDB
Une url du type : http://localhost:5984/<nom_de_la_db>/_design/<nom_du_design>/_show/<nom_du_show>/<id_du_document>

Et ta liste, tu me la montres aussi ?

Pour les listes, c'est un peu plus complexe mais pas insurmontable

L'url est du type :

http://localhost:5984/<nom_de_la_db>/_design/<nom_du_design>/_list/<nom_de_la_liste>/<nom_de_la_vue>?<paramètres>

Supposons que je veuille créer la page d'accueil de mon application, celle-ci listant tous les favoris stockés. Le nom de la liste pourrait donc tout naturellement s'appeller "all" et le nom de la vue "favs". On pourrait imaginer avoir une liste "search" par ex pour afficher les résultats d'une recherche sur les favoris avec des paramètres de recherche.

Il faut donc bien avoir en tête qu'une liste est un moyen d'afficher une vue. Une même vue peut donc partager plusieurs listes.

Ex :

http://localhost:5984/myfav/_design/mycouchfav/_list/all/favs
http://localhost:5984/myfav/_design/mycouchfav/_list/search/favs?limit=25&key=%22python%22

Commençons donc par créer notre vue, avec le fichier views/favs/map.js

function(doc) {
    emit(doc._id, {title: doc.title, description: doc.description, url:doc.url })   
};

Cette fonction me renvoi tous les documents de mon instance, trié par "_id" et avec une série de variables (title, description, url - je ne les réexplique pas, ce sont les mêmes que précédemment).

Passons à notre liste : lists/all.js

Note : Pour ceux qui son en CouchDB >= 0.10.x, le code est à récupérer dans ce billet. Le code ci-dessous est valable pour CouchDB 0.9.x

function(head, row, req, info) {
  // !json templates.all
  // !code vendor/couchapp/path.js
  // !code vendor/couchapp/template.js
 
  return respondWith(req, {
    html : function() {
      if (head) {
        return template(templates.all.head, {
          assets : assetPath(),
        });
      } else if (row) {
        return template(templates.all.row, {
          fav: row.value,
        });
      } else {
        return template(templates.all.tail, {
            assets : assetPath(),
        });
      }
    },
  })
};

La nouveauté ici tient dans la fonction qui prend différents paramètres en compte (contenus honteusement récupérés de benoitc "Légo 2 : les listes"):

head: est renseigné lorsque couchdb envoie la tête de la vue. head est un objet contenant les paramètres "total-rows" et "offset" correspondant au résultat de la vue. Cela nous permet, par exemple comme dans l'exemple ci-dessus, afficher l'entête d'une page html en chargeant un template particulier.
row : la ligne de la vue actuellement envoyée par CouchDB.
req : un objet contenant les paramètres de la requête
row_info : un objet contenant les infos sur la ligne en cours, sa position, quel était la ligne précendente, quelle est la première ligne de la vue.

L'autre nouveauté tient dans la gestion des templates HTML :

Pour head, on va charger templates/all/head.html
Pour chaque ligne de résultat, on va charger templates/all/row.html
Une fois que les résultats de la requête sont épuisés, on va charger templates/all/tail.html (qui fait donc office de voiture-balai).

Contenu de templates/all/head.html :

<!DOCTYPE html>
<html>
  <head>
    <title>My favs</title>
    <link rel="stylesheet" href="../../screen.css" type="text/css"/>
  </head>
  <body>
    <div id="header">
      <h2>My favs...</h2>
    </div>
    <div id="content">
      <h1>Recently...</h1>
      <dl id="bookmarks">

Contenu de templates/all/row.html :

  <dt><a href="<%= fav.url %>"><%= fav.title %></a></dt>
  <dd><%= fav.description %></dd>

Contenu de templates/all/tail.html :

    </dl>
  </div>
</body>
<script src="/_utils/script/json2.js"></script>
<script src="/_utils/script/jquery.js"></script>
<script src="/_utils/script/jquery.couch.js"></script>
<script src="<%= assets %>/vendor/couchapp/jquery.couchapp.js"></script>
</html>

Il ne vous reste plus qu'à pousser vos modifications dans votre instane CouchDB (ici en mode verbeux pour bien voir ce qui est poussé) :

tetram:mycouchfav nicolas$ couchapp push -v myfav
[INFO] push lists/all.js
[INFO] push shows/fav.js
[INFO] push templates/all/head.html
[INFO] push templates/all/row.html
[INFO] push templates/all/tail.html
[INFO] push templates/fav.html
[INFO] push vendor/couchapp/_attachments/jquery.couchapp.js
[INFO] push vendor/couchapp/couchapp.js
[INFO] push vendor/couchapp/date.js
[INFO] push vendor/couchapp/path.js
[INFO] push vendor/couchapp/README.md
[INFO] push vendor/couchapp/template.js
[INFO] push views/favs/map.js
[INFO] process code macro: /Users/nicolas/Documents/Projets/CouchDB/mycouchfav/vendor/couchapp/template.js
[INFO] process code macro: /Users/nicolas/Documents/Projets/CouchDB/mycouchfav/vendor/couchapp/path.js
[INFO] process code macro: /Users/nicolas/Documents/Projets/CouchDB/mycouchfav/vendor/couchapp/path.js
[INFO] process code macro: /Users/nicolas/Documents/Projets/CouchDB/mycouchfav/vendor/couchapp/template.js
[INFO] Pushing CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchfav to design doc:
http://127.0.0.1:5984/myfav/_design/mycouchfav
[INFO] Visit your CouchApp here:
http://127.0.0.1:5984/myfav/_design/mycouchfav/index.html

Rendez vous ensuite sur : http://localhost:5984/myfav/_design/mycouchfav/_list/all/favs

Au bout du compte, nous venons de voir pour les listes :

Les listes comme moyen d'afficher une vue,
Cela se traduit par un fichier de vue (views/mon_de_ma_vue/map.js) et un fichier liste (lists/<nom_de_ma_liste>.js)
La liste est une fonction de type function(head, row, req, info)
On peut spliter les templates en head.html / row.html / tail.html
url de type : http://localhost:5984/<nom_de_la_db>/_design/<nom_du_design>/_list/<nom_de_la_liste>/<nom_de_la_vue>?<paramètres>

Au bout de cette "journée"

Nous avons vu aux termes des parties 1 et 2 :

Comment installer couchapp et générer le squelette d'une application Couchdb
Jouer un peu avec Futon pour créer des enregistrements dans CouchDB (même si je ne le couvre pas directement, voir pas du tout en fait)
Comment afficher des documents sous forme de "list/views" pour une collection de documents et de "show" pour un document de façon unitaire

Il reste encore plein de choses à voir (au moins à mon niveau) :

Voir comment on peut remplacer le "My favs ... " dans head.html par une variable extérieure au template (facile - déjà fait mais cela rajoutait une grande quantité d"infos à ce post déjà très long je pense...)
Mieux comprendre les "!json" et "!code"
Les options de tri
<insérer votre sujet ici via un commentaire>
...

Sources utiles

Les lectures indispensables pour faire ce tutoriel :

benoitc : "Légo 2 : les listes"
benoitc : "Légo 3 : Tu as vu comme mon doc rend bien ?"
CouchDB Wiki : "Formatting with Show and List"

Au passage, les nouveautés de CouchDB / Couchapp mentionnées pat Benoit sont des plus intéressantes (surtout pour les listes, plus souple/flexible a priori).

Merci à benoitc pour éclairer ma lanterne sur couchdb/couchapp ces derniers jours

Couchapp : créer votre première application CouchDB (Partie 1)

Nicolas Steinmetz — Sat, 27 Jun 2009 16:19:00 +0200

Je continue ma découverte de CouchDB avec Couchapp, logiciel qui se définit comme un ensemble d'outils pour simplifier le développement d'une application avec CouchDB.

Ce billet chercher à compléter / mettre à jour le billet de Benoit Chesneau : "Et les légos s'emboitèrent" que je vous conseille de lire par ailleurs.

Installation de Couchapp

tetram:CouchDB nicolas$ sudo easy_install couchapp

Cela vous installe couchapp 0.3.2 à ce jour.

Génération du squelette de votre application

tetram:CouchDB nicolas$ couchapp generate mycouchapp
[INFO] Generating a new CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchapp

Le contenu est le suivant :

tetram:CouchDB nicolas$ ls mycouchapp/
_attachments	lists		vendor
lib		shows		views

Pour pousser votre application dans votre instance CouchDB dans une base "monapp" :

tetram:CouchDB nicolas$ cd mycouchapp/
tetram:mycouchapp nicolas$ couchapp push monapp -v
[INFO] push vendor/couchapp/_attachments/jquery.couchapp.js
[INFO] push vendor/couchapp/couchapp.js
[INFO] push vendor/couchapp/date.js
[INFO] push vendor/couchapp/path.js
[INFO] push vendor/couchapp/README.md
[INFO] push vendor/couchapp/template.js
[INFO] Pushing CouchApp in /Users/nicolas/Documents/Projets/CouchDB/mycouchapp to design doc:
http://127.0.0.1:5984/monapp/_design/mycouchapp
[INFO] Visit your CouchApp here:
http://127.0.0.1:5984/monapp/_design/mycouchapp/index.html
[INFO] Attaching index.html (413)
[INFO] Attaching style/main.css (21)
[INFO] Attaching vendor/couchapp/jquery.couchapp.js (6984)

Si vous ouvrez votre navigateur sur http://127.0.0.1:5984/monapp/_design/mycouchapp/index.html, vous voyez l'écran suivant :

A ce stade, 2 commandes ont été utilisées :

generate : crée le squelette d'application
push : envoie l'application dans couchdb

Si vous voulez récupérer une application de couchdb, il faut utiliser la commande "clone". Cela permet d'éditer votre application couchdb depuis votre disque dur et non plus depuis futon par ex. Au passage, vous ne pouvez pas cloner votre application dans le même répertoire que l'initial :

tetram:mycouchapp nicolas$ cd ..
tetram:CouchDB nicolas$ couchapp clone http://127.0.0.1:5984/monapp/_design/mycouchapp
[CRITICAL] an app already exist here: mycouchapp

Il vous faut donc spécifier un chemin différent :

tetram:CouchDB nicolas$ couchapp clone http://127.0.0.1:5984/monapp/_design/mycouchapp mycouchapp-cloned
[INFO] Cloning mycouchapp to mycouchapp-cloned...
tetram:CouchDB nicolas$ ls mycouchapp-cloned/
_attachments	lib		shows		views
couchapp.json	lists		vendor

A noter que la version clonée a un fichier couchapp.json en plus et donc je ne connais pas encore l'intérêt / l'utilité à ce stade.

Si on revient un instant sur ces répertoires :

_attachments contiendra les fichiers attachés à votre application
views contient les vues
lists contient les listes de vues ; utilisées par ex pour une page listant les 10 derniers documents par ex style page d'accueil d'un blog.
shows contient les rendus d'un document ; la visualisation d'un article d'un blog par ex.
lib contient les modèles et macros
vendor contient des composants tiers fournis par couchapp pour le moment mais on peut imaginer je suppose d'autres briques tierces dans cet espace .

Voilà pour un début, dès que je suis plus clair sur les listes / vues / rendus, vous aurez droit à un autre billet

Lecture : High Performance MySQL

Nicolas Steinmetz — Wed, 17 Jun 2009 11:56:00 +0200

L'intranet du groupe JCDecaux utilisant MySQL comme base de données, et devant travailler sur les problématiques de scalabilité / Plan de reprise d'activité, je m'étais acheté le livre "High Performance MySQL", considéré comme la référence en la matière. Autant le dire de suite, je n'ai pas été déçu et s'il avait été publié chez Apress, il aurait été appelé sans aucun doute : "MySQL : The definitive guide".

Contrairement à ce que pourrait laisser croire le titre, il ne se focalise pas uniquement sur la performance. Ou sinon il faut l'entendre comme utiliser MySQL de façon performante à tous les niveaux (code, infrastructure, sécurité, backup, etc).

Le livre couvre les sujets suivants :

Architecture de MySQL (architecture logique, moteurs de stockage, etc)
Benchmark et profilage en vue de trouver les goulots d'étranglements
Optimisation des schema et des index
Optimisation des requêtes
Fonctionnalités avancées de MySQL (Vues, Cache, Partitionnement, Clés étrangères, etc)
Optimisation de la configuration du serveur MySQL
Optimisation système et logicielle d'un serveur MySQL
Réplication
Montée en charge et/ou haute dispo
Optimisation applicatives (Serveur web, Cache, etc)
Sauvegarde et restauration
Sécurité
Les status d'un serveur MySQL (Show status & co)
Outils de consultation, surveillance, analyse, etc d'un serveur MySQL

J'ai bien aimé :

La complétude du livre : même si je ne suis pas concerné par tous les chapitres, au moins on a au final une vue complète sur MySQL. Dans ce sens, il devrait être lu par toute personne touchant de près ou de loin à MySQL
La prudence / le pragmatisme / les conseils sur les aspects performance et sur les capacités de MySQL face à tel ou tel objectif.

J'aurais bien aimé :

Sur la réplication, un peu plus de détail sur l'implémentation de certaines typologies de réplication - seul le cas basique (maitre/esclave) est couvert techniquement. Pour les autres cas, c'est plus une présentation + SWOT qu'une implémentation qui est proposée dans le livre.
Peut être une meilleure formulation de certains ratios car pour réussir à en calculer certains, c'est pas aisé aisé.
Au niveau configuration, ils auraient pu parler de la surchage de la configuration par défaut (une mise à jour du tutoriel va arriver prochainement) via les directives include et/ou includedir.

Je n'ai pas aimé :

Rien

Par contre, moi qui était globalement un partisan de MySQL, j'avoue être un peu refroidi par certains cotés dans le cadre d'un déploiement en entreprise (lié à la lecture du livre et l'expérience d'intégration/production à JCDecaux) :

L'instructon "Stop Slave" jusqu'à la version 5.1.35 arrête la réplication sans attendre la fin de la transaction en cours.
La sauvegarde par copie physique des fichiers a l'air plus que fragile.
La sauvegarde par export logique (à la mysqldump) semble être la seule voie stable avec pour inconvénient de (re)jouer un grand nombre de requêtes SQL (et donc d'être plus longue qu'une sauvegarde physique)
La gestion des log innodb (/var/lib/mysql/ibdata* /var/lib/mysql/iblogfile*) que l'on ne peut pas purger sans reconstruire complètement son serveur. Le risque étant que ces fichiers remplissent la partition s'ils ne sont pas limitées en taille ou que si la taille est atteinte, alors votre applicatif est figé. Coté indisponibilité de service, c'est pas mal non plus...
Le fait de mixer des tables au format MyISAM et InnoDB créent des contraintes d'exploitation potentiellement assez intéressantes puisque suivant le type de table, il ne faudrait pas utiliser les mêmes options pour mysqldump par ex. De même au niveau tuning, vu les ressources limitées d'un serveur, l'arbitrage du tuning entre les 2 types de tables peut être globalement "sous-performant"

Du coup, je crains que MySQL, dans le contexte JCDecaux, se limite à des petits applicatifs ou avec une criticité pas trop élevée alors que SQL Server / Oracle sera utilisé pour le reste.