Une petite sélection de liens pour le mois de Juin:
Not doing Code Reviews? What’s your excuse?
Getting started with android development
What are your favorite Vim tricks?
GNU Screen: Working with the Scrollback Buffer
C++ clear winner in Google language tests
Scaling with MongoDB (or how Urban Airship abandoned it for PostgreSQL)
SECCURE Elliptic Curve Crypto Utility for Reliable Encryption
J’ai récemment eu à coder à mon taf des jeux de tests pour valider le comportement de mon serveur de pub, et pour ça, j’ai codé des petits scripts tout bête pour créer/modifier les données dans une base postgresql. J’aurai pu prendre un ORM tout fait (propel, doctrine…), mais j’ai juste codé mes classes tout bêtement et le plus simplement du monde. Un exemple:
Pour les requêtes d’insert, au lieu d’avoir des méthodes spécialisées dans chaque classe, j’ai codé juste une fonction save() qui prend l’objet à sauver, et qui parse grâce aux fonctions get_class_* ses propriétés pour générer les requêtes d’INSERT ou d’UPDATE. Cette fonction ressembait dans un premier temps à:
Ca me contentait dans pas mal de cas simples, mais très rapidement, cela à montré ses limites. J’avais besoin de connaître plus précisement les types des champs dans la base. Et la solution a été d’utiliser les annotations, pour ne pas avoir de longues et lourdes modifications à faire dans toutes mes classes d’objet. PHP ne propose pas out of the box un système complet d’annotation, mais incorpore les outils pour développer un comportement analogue: les classes Reflection.
Ces classes permettent de faire du « reverse engineering » sur les classes, les interfaces etc pour retrouver les différentes composantes de ces objets, qu’ils soient instanciés ou non. Et de plus, elles permettent de récupérer les commentaires des classes, des méthodes et des propriétés s’ils existent. Il n’y a qu’à les mettre en application:
Ce qui donne:
Il ne resterait plus maintenant qu’à définir ses keywords, parser les commentaires propement pis à coder son propre mini-orm sans modifier les objets finaux.
Et voilà un début:
buildSchema retournera dans cet exemple:
Pour finir, quelques petites références sur le sujet:
Et au final, au lieu de réinventer une roue bien vieille, je suis parti utiliser Addendum:
La génération des fichier core contiennent l’état de la mémoire d’un process, et a lieu généralement suite au crash de ce process. Sous Linux, le core dump est provoqué suite à la réception par le process de signaux spécifiques documentés dans le man 7 signal:
Signal Value Action Comment
----------------------------------------------------------------------
SIGQUIT 3 Core Quit from keyboard
SIGILL 4 Core Illegal Instruction
SIGABRT 6 Core Abort signal from abort(3)
SIGFPE 8 Core Floating point exception
SIGSEGV 11 Core Invalid memory reference
SIGBUS 10,7,10 Core Bus error (bad memory access)
SIGSYS 12,31,12 Core Bad argument to routine (SVr4)
SIGTRAP 5 Core Trace/breakpoint trap
SIGXCPU 24,24,30 Core CPU time limit exceeded (4.2BSD)
SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD)
Avant toute chose, il faut vérifier que le système est capable de générer ces fichiers. En effet, sous Ubuntu par exemple, la user limit (ulimit) pour la taille des fichiers core est nulle. Il faut donc permettre au système d’écrire des fichiers de taille illimité:
On peut trivialement vérifier que les fichiers core sont générés. On lance un shell, et on envoie un signal SIGSEGV qui va faire crasher ce nouveau process ($$) pour générer le core:
Cependant, parfois, on veut pouvoir controler un peu plus ce fichier, en particulier son nom et sa destination. Les noyaux Linux 2.6 permettent cela grace à la variable système kernel.core_pattern (ou /proc/sys/kernel/core_pattern) qui sert de template pour le nom de fichier et qui a comme valeur par défaut « core ». Ce template accepte un chemin absolu et les modificateurs de format suivant:
On décide donc de placer nos fichiers core dans /tmp/core, et qu’ils aient le format « timestamp.nom-executable.pid.uid:gid ». Pour cela, on modifie /proc/sys/kernel/core_pattern avec le format de notre choix:
Et on teste:
Il ne reste plus qu’à le configurer de manière à toujours reproduire ce comportement, en particulier après un reboot dy système. Pour cela, il n’y a qu’à ajouter la ligne suivante dans le fichier /etc/sysctl.conf:
De plus, pour conserver la valeur de ulimit, il faudra modifier /etc/security/limits.conf et affecter la valeur « unlimited » à l’item « core »:
#<domain> <type> <item> <value> * soft core unlimited
A noter que cette modification prendra effet au prochain log-in et non à l’ouverture d’une nouvelle console dans X.
Cet article est issu d’une précédente version de mon weblog, mais perdu dans l’oubli. Il remonte à Avril 2008. Je le remets ici à jour.
Un problème au taf, si ce n’est le prix du café au distributeur, est la non possibilité de se connecter sur sa box avec son ssh. Et bien, Dag Wiers propose une solution propre (qui n’oblige pas à installer son sshd sur le 443 et d’utiliser corkcrew), mais d’utiliser proxytunnel qui marche plutot bien.
Pour résumer la chose, cela implique d’avoir un serveur avec un apache où on a la main dessus, mod_proxy/mod_proxy_connect et mod_proxy_http d’installés, possiblement mod_ssl (mais ça crée un petit problème de taille à cause d’une non-feature d’apache2), et un peu de configuration.
N’ayant pas la main sur mon serveur au taf, c’est pas facile pour tester. J’ai donc aussi installé privoxy en local pour faire mes tests. Par contre, après utilisation, j’ai pas réussi à faire passer un CONNECT sur un port de destination 80, privoxy ne voulait pas, et le limit-connect semblait pas vouloir être changé. En même temps il était 5h du mat, j’ai peut être oublié un truc.
Alors, voilà la conf que j’ai faite sur ma debian (serveur ssh):
Server ssh sur le 22 et 2222;
Apache2 de base installé (bon, avec php mais là on s’en fiche);
On configure le bouzin:
Il faut générer un certificat (.pem) pour notre nouveau serveur https. Pour çà, y a un super outil dans debian, et c’est make-ssl-cert:
Et un virtualhost sur le 443, qui inclue directement les directives pour mod_ssl et mod_proxy:
Un redémarrage d’apache, et on va tester avec stunnel:
Sur une autre console:
Hum. Ca ne fonctionne pas.
Un peu de recherche (ou de triche, car Dag Wieers donne la réponse), Apache, ou plus précisement le mod_proxy_connect est buggé. Mais un patch existe. Il faut appliquer un des patchs proposés (surement le dernier en date, dans mon exemple celui pour 2.2.16), et lancer un coup de rebuild des packages apache via les scripts debian:
… et c’est parti pour tout rebuilder: …
… et finalement on met à jour le package apache2.2-bin:
On reteste avec stunnel:
Yay ! First step donne. Plus qu’à tester via un proxy http et utiliser le client ssh.
Pour tester, j’installe en local un privoxy:
On pourra modifier l’adresse d’écoute de privoxy (localhost:8118), et le modifier (par exemple, 127.0.0.1:8080 pour éviter qu’il prenne l’adresse ipv6 au lieu de la v4).
On crée un profil ssh en accord, dans ~/.ssh/config:
On notera dans mon exemple que j’utilise le flag -X. Il permet de préciser que j’utilise une connection sécurisée ssl entre les deux proxy (entre mon proxy et le mod_proxy de mon apache). Il est possible que le proxy que vous utiliserez ne l’aime pas. Dans ce cas, n’hésitez pas à joeur avec -X, -e et -E).
Et si on restestait:
What ?!
Dans les logs, on voit:
Il n’aime pas trop que j’utilise « spine-proxy » comme alias. Solution, retirer le -d %h:%p (et le remplacer par le vrai host de la machine), ou changer l’alias. Après correction:
Et ça marche ! Rock’n'Roll ! :°)
Pour BUTT j’ai voulu un mini système de plugins/modules afin de rajouter ou modifier du code sans redémarrer mon process. Et Python propose nativement cela grâce au module imp. On va utiliser spécifiquement la procédure load_source qui permet de charger un fichier source, de le parser, et de retourner son objet Module.
Illustrons. Voici le code du très simple module à importer:
Procédure de chargement du module:
Il ne reste plus qu’à montrer par l’exemple le fonctionnement et le reload d’un module dans le main:
Qui nous donnera:
Le code modifié (ici test.py a été remplacé par test_new.py, qui contient du code modifié) a bien été relu par python et est à présent utilisé.