Octopuce

Optimisation SQL, EXPLAIN et les fonctions dans WHERE

Benjamin Sonntag — 2013-03-27T13:04:37Z

Chez Octopuce, en tant qu'hébergeur à forte valeur ajouté, nous aidons souvent nos client à optimiser leur MySQL, leur Apache, leur PHP, ou d'autres services du même genre.

Nous tombons parfois, pour nos clients les plus gros, sur des problème qui peuvent aller jusqu'à mettre à mal leur performance, et nos compétences purement système ne suffisent plus.

Aujourd'hui, je vous propose un exemple simple : comment optimiser une requête MySQL complexe et gagner énormément de temps à la génération d'une page web.

Pour cela, on utilise classiquement la directive EXPLAIN de MySQL, qui permet de demander à MySQL ce qu'il fera quand il exécutera une telle requête. On l'utilise en ajoutant le mot clef EXPLAIN avant un SELECT.

Prenons un exemple réel (légèrement modifié pour anonymiser le client) :

SELECT DISTINCT(F.ref),F.date_creation, CONCAT(P.nom,' ',P.prenom)
 FROM client P, formulaire F, suivi S
 WHERE P.ref = F.ref
 AND F.ref = S.ref
 AND S.etat = 1
 AND NOW()>=DATE_ADD(F.date_creation, INTERVAL 5 MINUTE)
 AND NOW()<=DATE_ADD(F.date_creation,INTERVAL 1 DAY);

On remarque que cette requête effectue une jointure sur 3 tables, avec un filtrage (WHERE) complexe et un DISTINCT() pour couronner le tout ...

Savoir si cette requête utilisera bien les index présents dans la table est complexe. Pour rappel, on met les index d'une table dès qu'on a l'intention de faire une requête utilisant ce champ dans la clause WHERE.

En ajoutant EXPLAIN, on obtient :

EXPLAIN SELECT DISTINCT(F.ref),F.date_creation, CONCAT(P.nom,' ',P.prenom)
 FROM client P, formulaire F, suivi S
 WHERE P.ref = F.ref
 AND F.ref = S.ref
 AND S.etat = 1
 AND NOW()>=DATE_ADD(F.date_creation, INTERVAL 5 MINUTE)
 AND NOW()<=DATE_ADD(F.date_creation,INTERVAL 1 DAY);

MySQL nous dit ainsi, pour chaque élément du WHERE (ou le distinct ici) quel index il pourrait utiliser (possible_keys) et quels index il utilise effectivement (key). Ce faisant, il nous déduit (dans rows) le nombre de ligne qu'il devra scanner pour cette requête est de 500 000 ! Le temps d'une telle requête est, sur un serveur optimisé, de 2.3 secondes...

On voit donc une chose intéressante : dans cette partie du WHERE :

AND NOW()>=DATE_ADD(F.date_creation, INTERVAL 5 MINUTE)
 AND NOW()<=DATE_ADD(F.date_creation,INTERVAL 1 DAY);

nous utilisons le champ F.date_creation. Or ce champs a bien un index comme nous le montre

SHOW CREATE TABLE formulaire;
 ...
 PRIMARY KEY (`ref`),
 KEY `date_creation` (`date_creation`),
 ...

Alors pourquoi MySQL n'utilise pas cet index ? Tout simplement parce que dans la requête, on passe ce champ à travers une fonction (ici DATE_ADD), l'index ne peut donc pas être utilisé, puisqu'on ne cherche pas une valeur ou un plage de valeur précise de ce champ !

On peut donc essayer de permettre à MySQL d'utiliser cet index en inversant la condition :

AND NOW()>=DATE_ADD(F.date_creation, INTERVAL 5 MINUTE)
 AND NOW()<=DATE_ADD(F.date_creation,INTERVAL 1 DAY);

devient alors

AND DATE_SUB(NOW(), INTERVAL 5 MINUTE)>=F.date_creation 
 AND DATE_SUB(NOW(),INTERVAL 1 DAY)<=F.date_creation;

et EXPLAIN de notre SELECT nous retourne désormais :

Et la durée de la requête tombe à 0.02 secondes !

La règle à suivre est donc :

Dans la mesure du possible, toujours éviter les appels de fonctions portant sur un champ, si on peut mettre l'appel de fonction de l'autre côté du test

Par ailleurs, il est parfois utile d'inverser l'appel de fonction même si on a un champ des deux côtés :

si on a un

DATE_SUB(t1.date_creation, INTERVAL 7 DAY) <= t2.date_creation

on peut essayer de le remplacer par

t1.date_creation <= DATE_ADD(t2.date_creation, INTERVAL 7 DAY)

Cela peut s'avérer utile si la création d'un index sur t1.date_creation serait trop coûteuse (grosse table, ou table souvent modifiée) ou si un index existe déjà pour t2.date_creation, ou encore si la cardinalité de t1 est plus forte que celle de t2 !

Javascript : le futur du web ?

Alban Crommer — 2012-12-06T16:22:54Z

Javascript est le langage de programmation dominant en 2012

Ce graphique est une copie des stats de Github concernant les projets hébergés. Tous les projets ne sont pas intégralement basés sur Javascript et Github n'est qu'une partie infime de l'informatique réellement déployée. Mais. C'est le symptôme d'une évolution certaine. DHTML, AJAX, WEB 2.0, jQuery et maintenant NodeJS. Aussi trollesque que soit mon accroche, Javascript sera un élément majeur de la prochaine génération de logiciels.

L'autre jour on comparait PHP et JS. Même mauvaise réputation auprès des vrais programmeurs mais malgré des défauts reconnus PHP est devenu le langage web le plus répandu. Il est passé du script de template à un langage de frameworks MVC "sérieux" (Zend, CodeIgniter, Symfony), un facteur de réussite parmi d'autres dont l'existence d'une aide fournissant une abondance de snippets à copier/coller ; sa symbiose avec Apache HTTPD et MySQL appréciés par les administrateurs système ; une gestion des modules assez limitée qui évite de partir dans un modèle diffus à la CPAN ; et il faut bien le dire une instance centrale contrôlant le développement du langage.

Tandis que de l'autre côté JS n'avait pas d'aide centralisée, était dépendant des implémentations des différents éditeurs de navigateurs, avec des méthodes pourries pour faire marcher le même code partout, sans parler des lenteurs. D'où longtemps un truc pas excitant. Et avec des défauts structurels évidents toujours renouvelés. Aujourd'hui, une interface sans JS, c'est dépassé, on fait tout en AJAX, et du coup on se retrouve à devoir implémenter les mêmes modèles en JS et en PHP (ou autre). Ce qui est idiot parce qu'on écrit tout en double et que les bugs ne peuvent que se multiplier.

Javascript un langage "sérieux" côté serveur ?

La première fois que j'ai entendu parler de NodeJS, j'ai eu du mal à croire qu'on veuille faire tourner du Javascript côté serveur. Je suis vraiment devenu un vieux con sérieux, non ? Le plus serait en dehors de la réduction du code que ça mette les données au centre de l'application avec une forme d'ORM et de synchro automatique. Mais ça n'a de sens qu'à condition de disposer de frameworks permettant de conserver les bénéfices actuels.

Sécurité Filtrage des données, Sécurisation des accès, Gestion des ACLs

Stabilité Application serveur robuste, pas de DOS, des scripts interdépendants sans compilation

Déployabilité Simplicité d'installation, Interdépendance des applications au sein d'un serveur

Qu'en est-il ? Wikipedia fait une comparaison de solutions existantes et j'ai de mon côté relevé celles-ci en attendant de les tester

NodeJS (Sa fiche sur Wikipedia) Node est un serveur (et pas un framework) encore jeune et évoluant rapidement. Du point de vue sécurité, si je crains le pire, les buffer overflows sont pour tout le monde ;). Pour la stabilité il faut relancer chaque application à la main en cas de plantage du serveur, donc médiocre. Et sur l'aspect déploiement il semble que ce soit plus infernal qu'autre chose à l'heure actuelle côté serveur pour l'administrateur Linux. L'argument de Node est d'être plus rapide et plus "scalable". A voir. Une fois Node installé, il faut choisir ses outils de développement, et là ça se complique.

Quelques frameworks Node

Geddy, Express et son parent Connect, Flatiron ... il est clair les Frameworks Node ne manquent pas, sans compter les modules du NPM qui permettent de recomposer son propre stack en fonction de ses besoins. Aperçu de quelques .

Connect est le premier framework Node ayant "décollé". Il met à disposition un grand nombre de fonctionnalités essentielles et dispose de nombreux composants additionnels. Au niveau sécurité, il met à disposition un nombre minimal d'objets ( csrf par exemple ) mais la validation requiert des éléments supplémentaires.

Express : basé sur Connect, Express offre une gestion facilitée en MVC. Au niveau sécurité des entrées / sorties il améliore certes Express mais pas tant que ça.

Geddy : est une version plus complète, avec une sécurité améliorée, une gestion du scaffolding en ligne de commande et de l'ORM. Également basé sur Express il adopte le modèle MVC avec validateurs et gestion des vues. Il peut travailler avec plusieurs backends SQL & noSQL. Il semble que RailwayJS qui a pour objectif d'introduire les idées de Rails dans Node soit assez proche et bien pensé.

Flatiron est (encore) une autre solution qui combine plusieurs modules pour fournir les services de base attendus d'un framework MVC comme le routage, les logs, la gestion du backend et des vues. Son argument est identique à celui des autres projets : simple, "non-obstrusif", léger.

D'autres solutions existent pour Node (Matador, Monorail, Grasshoper ... ) qui se fondent toutes sur ces mêmes arguments et il faut bien l'avouer, de loin ont un air de ressemblance assez marqué ;).

Et en dehors de Node ? Backbone & co.

NodeJS apparaît comme une boîte à outils avec un gestionnaire npm intéressant mais d'autres approches existent, dont un certain nombre exécutent le routage de l'application côté client, en gros en limitant au maximum les échanges entre le serveur et l'application à des appels d'API sans html. Ce qui entre autre laisse entrevoir des possibilités importantes concernant l'utilisation offline et le stockage en local.

BackboneJS (page wikipedia) est une référence autant que Node peut l'être. Comment marche Backbone ? Dit simplement, il met à disposition du navigateur tout ce qui est nécessaire pour transformer les données brutes reçues du serveur, les modifier et les renvoyer. Il s'appuie notamment sur la dimension prototypique de javascript pour les objets autorisant leur modification à chaud (ie. Monkey Patching et Duck Typing). Backbone est notamment réputé pour son efficacité en tant que client mobile universel : à la fois léger en terme de code et d'échanges réseau, il s'adapte bien à tous les systèmes. Exemple : Soundcloud l'a utilisé pour son client mobile et désormais va l'utiliser partout. Une fois encore, l'argument de légèreté, d'interdépendance et de simplicité est récurrent : Backbone n'a qu'une seule dépendance (UnderscoreJS) et laisse le choix des outils de template par exemple.

Et alors, côté serveur ? Pour en revenir aux critères de départ, la sécurité par validation est limitée et bon nombre de choses ne sont pas fournies. La stabilité est plutôt bonne avec un minimum de ressources côté serveur . Backbone échangeant directement des objects en JSON, la solution "naturelle" consiste à stocker les données dans une base NoSQL comme MongoDB en utilisant les mêmes objets pour la validation. Mais on pourrait aussi faire un backend dans un autre langage (genre PHP MyQL). Idem pour le déploiement, il peut être de fait minimal.

EmberJS est une solution plus récente qui se base sur le modèle de Backbone en ajoutant notamment une automatisation des changements d'apparence reliée aux flux de données. Si elle offre plus de fonctionnalités c'est au détriment de la simplicité. http://smus.com/backbone-and-ember/

SpineJS dans cette lignée est très complet : MVC, ORM, échanges asynchrone, relation directe entre affichage et données, stockage navigateur, version Mobile : pas grand-chose à demander de plus. C'est un framework encore jeune mais prometteur.

ExtJS page wiki a connu plusieurs itérations. Il se présente comme une solution plus lourde offrant traditionellement une palette de composants. Il offre désormais en plus du MVC, une interface RestFul et des méthodes de générations de graphiques. Dans l'ensemble orienté vers l'application "Desktop" il manque certaines fonctionnalités importantes comme la validation de données. De même l'ORM est disponible mais sous forme de plugin externe.

Il y en a d'autres, cette liste (en anglais) donne les avantages et inconvénients. Un point intéressant concerne notamment la simplicité du "data binding", en d'autres mots la mise en relation entre éléments de l'interface et sources de données dans les vues pour parvenir à des mises à jour automatiques. En l'occurence si certaines formes sont un peu laborieuses comme dans Knockout

First name:

Dans Ember en revanche on déclare les bindings directement dans l'objet

... attributeBindings : ['data','value','format','readonly','type','size'], ...

Ce qui est effectivement beaucoup plus léger et centralisé.

Automatisation des relations entre données et objets

Un des principes directeurs des différentes solutions évoquées, en tout cas parmi les plus avancées, consiste à simplifier au maximum le travail du développeur grâce à une définition des objets permettant à la fois leur manipulation, leur affichage, leur validation et leur stockage. Soit à mon sens une continuation des méthodes d'ORM/scaffolding utilisées notamment par Django ou Rails. C'est à mon sens une direction intéressante ; la dernière application PHP que j'ai testé dans ce domaine est PimCore qui s'appuie sur ExtJS pour proposer une ORM qui génère des fichiers de classes modifiables et des tables de bases de données tout en présentant graphiquement les champs comme des composants de formulaire, avec la possibilité de modifier son modèle en fonction des besoins. Pour la plupart des interfaces de gestion c'est une solution intéressante, rapide et souple.

Autre paradigme intéressant, l'échange direct d'objets sérialisés entre frontend et backend, qui justifie pleinement l'emploi de bases de données orientées document pour y stocker les objets json. Les problèmes d'indexation que connaissent ces bases sont connus mais à l'avenir ce genre de technique devrait largement justifier leur utilisation.

Conclusions

Première conclusion évidente, il y a une diversité de solutions qui répondent à des moyens et des besoins (taille du projet, temps de déploiement) différents. En l'état il n'y a pas de solution qui se dégage absolument mais un paysage contrasté et évoluant rapidement.

Les bénéfices potentiels qu'apportent les nouvelles solutions, dont il faut bien observer qu'elles reviennent à faire du Flash en HTML5, vont par nécessité devenir la norme des applications webs haut de gamme et évoluées, tant elles peuvent avoir des attraits importants pour les utilisateurs en terme de confort et de portabilité.

Ensuite, il apparaît que certaines sont relativement faciles à déployer dans un environnement Linux du fait de leur exécution côté client, bien qu'à terme pouvoir exécuter du code JS côté serveur soit déterminant dans l'optique de l'isomorphisme du code (ie. modèles identiques des deux côtés), permettant de bénéficier au maximum de javascript.

Dans la mesure où l'on peut utiliser des backends solides on peut tout à fait utiliser ces techniques pour réaliser des applications web de gestion "sérieuses" qui resteront néanmoins coûteuses à produire.

Il apparaît aussi que NodeJS et nombre de ces solutions soient utilisés pour des applications à forte demande. Ce qui est assez amusant tant l'évocation de cette idée tend à faire fuir immédiatement un administrateur système traditionnel :)

TL ;DR

Wooh ! new JS code is awesome ! But... Hey guys did you know... that ummm... Your apps ? They need to deploy everywhere and be safe !

Octopuce à Metz (Libre et Entreprises)

Chantal Bernard-Putz — 2011-10-23T08:18:47Z

Octopuce sera présent à la journée "Entreprises et Logiciels Libres" organisée par Moselle Numérique, le 28 octobre 2011.

Notre entreprise Octopuce sera présente à la journée "Entreprises et Logiciels Libres" organisée à Metz par Moselle Numérique, le 28 octobre 2011.

Chantal Bernard-Putz animera deux échanges :

Les logiciels libres : leur place (quels domaines ? quels usages ?) dans les entreprises. Leurs avantages dans un environnement professionnel. Pourquoi, à qualité égale opter pour le libre ?
Comment et où puis-je trouver de l'information sur le libre et me faire aider pour le déploiement dans mon entreprise (en collaboration avec les acteurs du Libre de Lorlibre)

Elle animera également un atelier :

Authentifier et chiffrer ses échanges sur internet avec des outils libres et légaux

Et présentera nos offres sur un stand, toute la journée.

Télécharger le programme de la journée

Comment utiliser les hooks de GIT pour mettre à jour automatiquement un site de développement

Benjamin Sonntag — 2011-01-19T17:50:00Z

Après avoir vu comment utiliser Gitosis sur un serveur pour y centraliser ses dépôts de source pour vos projets, nous allons voir comment mettre à jour automatiquement votre serveur de développement via les hooks de Git.

En effet, il nous est souvent demandé de pouvoir mettre à jour automatiquement les sources de la version de développement à chaque push d'un développeur. Pour cela, nous allons utiliser 2 outils très utiles : sudo (qui permet à Git de se faire passer pour votre compte web) et les hooks de Git (qui permettent de déclencher une action à chaque push.)

Pour cela, on procède ainsi :

Créer un script /usr/local/bin/pullhere comme suit :

#!/bin/sh
 cd "$1" 
 git pull

rendez-le exécutable via

chmod a+x /usr/local/bin/pullhere

modifier sudo pour permettre à l'utilisateur de gitosis d'utiliser cette commande en tant que www-data.

Pour cela, en lançant "visudo" ajoutez la ligne :

git ALL = (www-data) NOPASSWD: /usr/local/bin/pullhere

ensuite, dans chaque dépot où cela est nécessaire, ajoutez le hook suivant dans un fichier post-receive :

sudo -u www-data /usr/local/bin/pullhere /html/u/user/here

par exemple : dans /home/git/repositories/projet1.git/hooks/post-receive

attention : ce dossier (hooks) contient un exemple nommé "post-receive.sample" ce n'est pas ici qu'il faut créer votre ligne sudo, mais bien dans post-receive tout court (créez-le si besoin)

Enfin, rendez ce fichier exécutable comme suit :

chmod a+x /home/git/repositories/projet1.git/hooks/post-receive

ainsi, à chaque fois qu'un utilisateur effectuera un push sur ce dépôt git dans gitosis, un pull sera automatiquement effectué dans le dossier web de votre site de développement.

Dernière étape, il faut effectuer le clonage de votre git à l'endroit du site de développement (ici /html/u/user/here) pour cela, on procède ainsi :

cd /html/u/user/here
 git clone /home/git/repositories/projet1.git

Hébergement de dépôts GIT sur un serveur via Gitosis

Benjamin Sonntag — 2011-01-18T10:48:00Z

Octopuce hébergeant de nombreuses agences web, leurs clients et les projets de développement de tout ce petit monde, il nous est souvent demandé d'installer des systèmes de contrôle de version.

Nous utilisions jusque là subversion (svn) mais certains de nos clients utilisent maintenant GIT, le nouveau système de gestion de source distribué, visiblement plus léger et rapide que svn.

Nous avons donc dû nous poser la question de l'hébergement de ces dépôts GIT. Rapidement, nous sommes tombés sur le logiciel Gitosis, qui permet de gérer facilement ses dépôts git avec un accès SSH, mais sans nécessité de disposer d'un accès shell au serveur !

Voici donc comment utiliser gitosis sous Debian pour créer des dépôts

Gitosis, mode d'emploi

gitosis est facile à utiliser notamment par le fait qu'un package pour Debian existe, qui nous pose les 3 questions nécessaires au bon fonctionnement de gitosis : le nom du compte de gitosis (je conseille "git", court est explicite), le chemin dans lequel on stockera les sources (je conseille /home/git) et la première clé qui sera autorisée à utiliser le dépôt principal. Donc pour l'installer, il faut lancer sur le serveur de sources :

aptitude install gitosis git-core

Un dépôt "principal", nommé "gitosis-admin.git", permet d'administrer les droits d'accès aux dépôts sur le serveur. En effet, c'est via un dépôt GIT que Gitosis gère la liste des clés autorisées et la liste des autorisations d'accès en lecture ou en écriture aux dépôts.

Une fois gitosis installé (avec votre clé ssh personnelle) utilisez la commande suivante pour obtenir une copie locale du dépôt gitosis-admin :

git clone git@votreserveur.fr:gitosis-admin.git

vous obtiendrez un dossier gitosis-admin/ contenant un fichier gitosis.conf (dans lequel on définit les droits d'accès aux dépôts pour chaque liste d'utilisateur) et un dossier keydir/ dans lequel on créera un fichier au nom d'un utilisateur contenant la clé SSH publique de cet utilisateur.

Une fois cela fait, on envoie ces nouveaux fichiers sur le serveur gitosis via

git add . 
 git commit -a -m "ajout clefs et projets"
 git push

Par exemple, j'ai créé un groupe "octopuce" dans mon gitosis.conf, dans lequel les utilisateurs (listés dans la directive "members") ont droit d'accès en écriture (via la directive "writable") à des dépôts particuliers :

[gitosis]
 
 [gitosis-octopuce]
 writable = gitosis-admin projet1 projet2
 members = benjamin said

ainsi, dans keydir, j'aurais créé les fichiers "benjamin" et "said" contenant les clés de Saïd et Benjamin.

Une fois cela fait, on peut créer le dépôt, par exemple pour le projet1. pour créer le dépôt, sur votre ordinateur, créez vos premiers fichiers source, et tapez :

# On crée le dépôt local quelque part sur sa station de travail : 
 mkdir projet1
 cd projet1
 git init
 # On signale à git qu'il sera envoyé sur le serveur :
 git remote add origin git@votreserveur.fr:projet1.git
 # On lui ajoute les premiers fichiers : 
 touch README
 echo "Premier fichier d'initialisation" > README
 git add . 
 # Que l'on valide : 
 git commit -am "initialisation du projet1"
 # Enfin, on envoie tout cela sur le serveur.
 git push origin master:refs/heads/master

Et voilà, votre premier dépôt a été créé sur git.

Dans l'article suivant, nous verrons comment utiliser les hooks de git pour mettre à jour automatiquement un site de développement

112. Mondomix

Saïd Bouaïssi — 2011-01-11T16:08:42Z

Mondomix est un media numérique dédié à l'actualité et à la découverte des cultures et musiques du monde entier. Octopuce gère l'infrastructure d'hébergement web de ses sites propres (dont le magazine des cultures du monde) et des créations de l'Atelier 144.

Voir en ligne : http://www.mondomix.com

110. Price Water House Coopers France

Saïd Bouaïssi — 2011-01-11T15:52:56Z

PricewaterhouseCoopers (« PwC ») développe en France des missions d'audit, d'expertise comptable et de conseil pour des entreprises de toutes tailles, publiques et privées. Octopuce est en charge de l'administration système des serveurs Linux de PWC France.

Voir en ligne : http://www.pwc.fr

apt-mirror : BADSIG on security.debian.org (with solution)

Benjamin Sonntag — 2010-11-26T11:08:18Z

At Octopuce, we are Debian professional and are using Debian everywhere we can. For one of our customers, we maintained a mirror of Debian repositories, which are used by internal Linux servers.

This mirror is using apt-mirror since we cannot access the Internet by rsync or ftp protocol : we have to use http to mirror the repositories.

A few days ago, I saw the following error message on a Linux Debian server using this internal mirror :

 W: GPG error: http://fr-debianmirror lenny/updates Release: The following signatures were invalid: BADSIG 9AA38DCD55BE302B Debian Archive Automatic Signing Key (5.0/lenny) 
 W: You may want to run apt-get update to correct these problems

This issue was critical : the GPG signature of debian security repository was incorrect !! There were 3 places were this could happen :

At the Debian repository security.debian.org : I don't think so, or google would have told me ;)
During the mirroring process : maybe ...
At the final server location : each Debian machine have a GPG keyring of allowed keys for repository signature. The apt-key tool is used to manage this keyring, located at /etc/apt/trusted.gpg and /etc/apt/trustdb.gpg

chack apt-key configuration

First, check if the command "apt-key list" tell you that the faulty key is allowed. If it is not, you may add it by installing the proper debian package, for example :

aptitude install debian-archive-keyring

some people in the Internet tell you to use gpg —keyserver keyserver.fr —recv-key 0x9AA38DCD55BE302B | apt-key add -

but using the debian package should work "the right way" :)

Check the mirror

Of course, our Debian servers where properly installed, so we already had the ftpmaster Debian archive GPG key in our servers.

Next step: I checked the faulty file : it was located at /var/spool/apt-mirror/mirror/security.debian.org/debian-security/dists/lenny/updates/Release.gpg

This file should be a GPG signature of the Release file, located in the same directory.

There, I saw this :

.../debian-security/dists/lenny/updates/$ ls -l
 -rw-r--r-- 1 apt-mirror 835 2010-10-20 10:13 Release.gpg
 -rw-r--r-- 1 apt-mirror 40K 2010-11-22 21:12 Release

And here it looks obvious to me we have a problem: a signature cannot be older than the file it is signing !

In fact, our apt-mirror (which is using wget to download files) is using a proxy server to connect to the officials Debian mirrors. As such, I put the following in /etc/wgetrc :

http_proxy = http://10.42.12.12:8080/

and here is the problem: this proxy is unable to detect when the release.gpg file has been modified, and as such, he often returns an old version of this file !

To check this theory, I used wget with -S to see the HTTP headers returned by the server and the proxy :

fr-debianmirror:/tmp# wget http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg -S
 --2010-11-26 12:08:43-- http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg
 Connecting to 10.42.12.12:8080... connected.
 Proxy request sent, awaiting response...
 HTTP/1.1 200 OK
 Date: Fri, 26 Nov 2010 10:57:06 GMT
 Server: Apache
 Last-Modified: Mon, 20 Oct 2010 10:13:36 GMT
 ETag: "343-e08fc449a1532"
 Accept-Ranges: bytes
 Content-Type: text/plain
 Content-Length: 835
 Connection: close
 Age: 855
 Length: 835 [text/plain]

the lines in bold are the guilty one : the last modified date is not the right one, and the Age header tells us how old in the proxy cache is this entry.

Our solution

So, the solution was to tell wget to ask the proxy for a fresh version by using the —no-cache directive. A better way to use this is to add this line to /etc/wgetrc :

cache = off

and here we are :

wget http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg -S
 --2010-11-26 12:17:39-- http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg
 Connecting to 10.42.12.12:8080... connected.
 Proxy request sent, awaiting response...
 HTTP/1.1 200 OK
 Date: Fri, 26 Nov 2010 11:05:58 GMT
 Server: Apache
 Last-Modified: Mon, 22 Nov 2010 20:12:36 GMT
 ETag: "343-495a9e08a1500"
 Accept-Ranges: bytes
 Content-Type: text/plain
 Content-Length: 835
 Connection: close
 Age: 0
 Length: 835 [text/plain]

SFTP pour Openssh : comment logguer qui a fait quoi ?

Benjamin Sonntag — 2010-08-27T13:49:04Z

Dans la série truc & astuces, nous avons du récemment ouvrir des accès SFTP à certains de nos clients ou partenaires.

Étant très pointilleux sur la sécurité de nos infrastructures et celle de nos clients, nous avons souhaité pouvoir logguer qui effectuait quel transfert en SFTP sur le serveur correspondant (en plus d'y mettre un chroot...)

Or, par défaut, openssh et son serveur sftp-server ne loggue pas qui transfère (en lecture, écriture ou effacement) quel fichier.

Cependant, depuis la version 4.2, sfp-server sait logguer ce type d'action. Pour cela, il suffit de configurer votre sshd comme suit :

La ligne du sftp:

Subsystem sftp /usr/lib/openssh/sftp-server

doit être remplacée par la ligne ci-dessous :

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO -f LOCAL0

Après redémarrage de ssh par /etc/init.d/ssh restart, on obtient, dans /var/log/syslog :

Aug 27 15:29:15 mg sftp-server[12]: session opened for local user admin from [91.194.61.194]
 Aug 27 15:29:15 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:15 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:24 mg sftp-server[12]: open "/home/admin/test.txt" flags READ mode 0666
 Aug 27 15:29:24 mg sftp-server[12]: close "/home/admin/test.txt" bytes read 5069 written 0
 Aug 27 15:29:31 mg sftp-server[12]: open "/home/admin/test.txt" flags WRITE,CREATE,TRUNCATE,EXCL mode 0666
 Aug 27 15:29:31 mg sftp-server[12]: close "/home/admin/test.txt" bytes read 0 written 184
 Aug 27 15:29:31 mg sftp-server[12]: set "/home/admin/test.txt" modtime 20100528-12:11:29
 Aug 27 15:29:31 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:31 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:34 mg sftp-server[12]: remove name "/home/admin/test.txt"
 Aug 27 15:29:34 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:34 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:39 mg sftp-server[12]: session closed for local user admin from [91.194.61.194]

IPv6 à Octopuce, une réalité

Benjamin Sonntag — 2010-07-27T06:21:50Z

Après près de un an à y réfléchir et à voir comment intégrer une dual stack (le mélange de IPv4 et IPv6 au sein de nos serveurs) et à tester diverses configurations, Octopuce a enfin obtenu et commence à déployer des adresses IPv6 sur son backbone d'hébergement !

Nous avons, le 14 juillet dernier, obtenu de l'autorité européenne de régulation de l'Internet (le RIPE, pour "Réseau IP Européen") un bloc d'IPv6 destiné à Octopuce, appellé bloc PI (pour Provider Independent) qui a pour joli préfixe 2001:67c:288 ::/48.

Nous disposons donc de la bagatelle de 1 208 925 819 614 629 174 706 176 adresses IPv6 disponibles pour nos hébergés.

Les premiers serveurs utilisant à la fois IPv4 et IPv6 sont installés et commencent à servir les pages web ou email indifféremment en v4 ou v6.

Si vous êtes un de nos clients et que vous souhaitez disposer de ces nouvelles possibilités, n'hésitez pas à nous contacter, nous nous ferons un plaisir de vous aider dans votre déploiement IPv6 sur vos infrastructures !