Depuis quelques temps, je développe pas mal en python et durant mes différents projets, j’ai rencontré tout un tas de petits problèmes ou besoins.

Je me suis donc dis que cela pourrait être intéressant de regrouper en vrac dans un article quelques unes des solutions trouvées. Non seulement cela vous servira peut être un jour, mais en plus, vous aurez peut être des solutions plus simples/adaptées à me proposer ;)

Opérateur ternaire

J’utilise souvent en php l’opérateur ternaire (x ? a : b) et je voulais trouver une équivalence en python.
Ma première réaction a été de faire simplement un :

bool(x) and a or b

Mais si « a » est un booléen à false, cela ne fonctionne pas comme le montre le petit test ci-dessous :

J’ai donc cherché plus en profondeur et j’ai trouvé une solution des plus simple en utilisant une liste avec 2 valeurs :

[a, b][bool(x)]

Suivant la valeur de « x », la valeur retournée sera la 0 ou la 1.

Récupérer son adresse IP publique

En python, pas possible de faire comme en PHP en utilisant $_SERVER['REMOTE_ADDR'] pour afficher l’IP. Il fallait donc trouver une solution, et après plusieurs minutes de recherche, la seule solution vraiment valable que j’ai trouvé, est toute simple.

from urllib2 import urlopen
public_ip = urlopen('http://whatismyip.org').read()

N.B: l’idéal serait d’utiliser un try … except pour faire propre mais bon, ca c’est à vous de le faire

Si vous connaissez une autre solution, je suis preneur ;)

Un serveur web instantané

Envie de partager un ou plusieurs fichiers avec quelqu’un sans devoir le mettre sur une url publique (ex: www.mondomaine.com/fichier_pour_toi.png) ou créer un compte FTP ? Envie d’analyser vos requêtes http ? Autre envie ?

Python vous permet en une ligne de commande de réaliser un serveur web :

python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"

Il vous suffit ensuite de vous connecter sur l’ip de votre serveur sur le port 8000 et naviguer dans l’arborescence du répertoire ou la commande à été lancée :

Pour arrêter le serveur, un petit « CTRL+C » dans votre shell et c’est fini ;)

N.B: il est tout a fait possible en une dizaine de lignes de faire un serveur un peu plus abouti avec notamment une gestion du port.

Envoyer un fichier par sftp

Envoyer un fichier (backup, sources …) d’un serveur à un autre est possible de différente façon (FTP, webdav …) mais une des manière les plus sécurisées et sans installation supplémentaire (quand le serveur autorise les accès ssh) reste pour moi le sftp.

Et j’ai trouvé « paramiko » qui existe en paquet debian, donc un simple « apt-get install python-paramiko » et hop.

Le code :

import paramiko
 
host = '127.0.0.1'
port = 22
transport = paramiko.Transport((host, port))
 
user = 'mon_user'
pass = 'mon_pass'
transport.connect(username = user, password = pass)
 
sftp = paramiko.SFTPClient.from_transport(transport)
 
import sys
path = sys.argv[2]
localpath = sys.argv[1]
sftp.put(localpath, path)
 
sftp.close()
transport.close()
print 'Upload done.'

Ensuite il suffit de lancer le script :

python send_over_sftp.py /chemin/local/fichier.txt /chemin/distant/fichier.txt

Et c’est tout :)

N.B: A noter qu’il est préférable de configurer ses serveurs pour fonctionner avec des clefs plutot que de mettre le password en clair dans le script python et de sécuriser les paramètres envoyés au script si vous donnez l’utilisation à d’autres utilisateurs.

PHP to PYTHON

Pour finir, un petit lien très pratique qui vous permet de voir l’équivalence python des fonctions php (quand elle existe) : http://www.php2python.com/

Récupérer la documentation sur git

La documentation officielle de Symfony2 est bien sur hébergée sur Git. Rendez-vous sur le dépôt Git officiel et clonez la documentation en local.

git clone git://github.com/symfony/symfony-docs.git

Installer Sphinx

Tout d’abord la documentation Symfony2 est générée grâce à Sphinx, un projet écrit en Python. Il serait donc de bon aloi de l’installer ;-)

Si comme tout gens bien vous utilisez ArchLinux, il vous suffit d’un petit

sudo pacman -S python-sphinx

Pour les autres utilisez easy_install directement :

easy_install -U Sphinx

SI vous n’avez pas easy_install (hey les gens, faut vraiment vous mettre au Python !), c’est par ici.

Créez un Makefile

Pour l’instant, le repo Git officiel ne fournit pas de Makefile pour générer la documentation. Il va donc falloir en créer un. Pour ce faire utilisez la commande suivante dans votre répertoire symfony-docs :

sphinx-quickstart

Cette commande va vous poser tout plein de questions, acceptez toujours les choix par défaut (appuyez sur entrée pour ce faire). Vous aurez juste trois choses à saisir, le nom du projet (mettez Symfony2), le nom de l’auteur (Fabien Potencier serait fair play ;-) ) et la version (est-ce un piège ?).
Lorsque cette question va arriver > Name of your master document (without suffix) mettez n’importe quoi d’autre que index, on s’en fiche un peu, mais si vous mettez index il va pas être content le mÔssieur.

Installez l’extension configuration

Fabien a du créer une extension pour gérer plusieurs formats (YAML/XML/PHP dans notre cas) pour les fichiers de configuration. Pour l’installer, créez un répertoire _exts dans votre répertoire symfony-docs et placez-y le fichier se trouvant sur le repo Git sphinx-php de Fabien.

Éditez le fichier conf.py qui se trouve dans symfony-docs, et ajoutez-y cette ligne en haut après la ligne d’import :

sys.path.append(os.path.abspath('_exts'))

Trouvez ensuite la ligne des extensions et rajoutez-y celle que l’on a téléchargée plus haut :

extensions = ['configurationblock']

Vous être prêt à générer votre première documentation Symfony2.

make html

Et voilà ! Le fichier index.html généré se trouve dans _build/html/index.html

Amusez-vous bien, et n’hésitez pas à contribuer dès que vous le pouvez.

Voici donc le code, résultat de cette réflexion, ou un clic avec ctrl (ou cmd pour les mac) ou le bouton du milieu de la souris devrait ouvrir le lien dans un nouvel onglet, comme le ferait un lien normal :

$('.line-click').live('click', function(e){
  e.stopPropagation();
  href = $(this).children('a:first').attr('href');
  if (e.ctrlKey || e.metaKey || e.which == 2) {
    window.open(href);
  } else {
    window.location = href;
  }
}).css('cursor', 'pointer');

A utiliser avec le code html suivant par exemple:

<ul>
  <li class="line-click"><img src="monimage.jpg" alt="youpi" /> 10/02/11 <a href="monlien.html">Titre de mon billet</a></li>
  <li class="line-click"><img src="monimage2.jpg" alt="youpi" /> 07/02/11 <a href="monlien2.html">Titre de mon 2e billet</a></li>
  <li class="line-click"><img src="monimage3.jpg" alt="youpi" /> 21/01/11 <a href="monlien3.html">Titre de mon 3e billet</a></li>
</ul>

A adapter selon vos envies. Ici c’est le premier lien trouvé dans l’élément avec la class line-click qui sera déclenché. Voilà, en attendant que j’arrive à finir un billet plus consistent!

Crédit photo : http://www.flickr.com/photos/flyingturtle/837938254

Suite à quelques demandes, notamment de @Ouark lors d’une soirée sur Paris, je vais essayer de publier régulièrement quelques petites astuces que j’ai trouvé et qui m’ont bien aidé/dépanné.

Voici donc la partie #2 des Tips concernant la configuration de serveurs et le développement.

Reset du pass root MySQL

Qui n’a jamais perdu son mot de passe root MySQL, ce mot de passe que l’on vous demande à l’installation et dont vous allez vous servir ponctuellement, préférant par sécurité utiliser des utilisateurs plus précis et associés à une BDD spécifique. Je ne suis surement pas le seul en tout cas ^^

Ne stockant jamais mes mots de passe (question de sécurité), le mot de passe root MySQL est celui que j’ai le plus souvent oublié, même si ca ne m’arrive pas toutes les semaine non plus. Voici donc une petite astuce pour le reset et en créer un nouveau sans devoir tout réinstaller.

1 – Arrêter votre serveur MySQL

La première chose à faire bien entendu, est d’arrêter MySQL, le tout en étant root sur la machine bien entendu (comme pour toutes les commandes qui suivront)

/etc/init.d/mysql stop

2 -MySQL en safe mode

Il faut maintenant lancer MySQL en safe mode avec l’option « –skip-grant-tables » pour ne pas prendre en compte la table des privilèges.

mysqld_safe --skip-grant-tables &

A noter aussi le « & » qui permet de lancer en background le serveur et ainsi continuer à modifier le pass root.

3 – Login

Maintenant on peut se loguer au serveur MySQL en root de manière « anonyme » ou plutôt sans avoir le soucis des privilèges

mysql --user=root mysql

4 – Modifier le pass root

Une fois connecté, il suffit d’effectuer une requête pour mettre à jour le pass de la table user.

UPDATE USER SET Password=PASSWORD('mon_nouveau_pass') WHERE USER='root';
FLUSH PRIVILEGES;

5 – C’est repartit !

Maintenant, on arrête le safe mode puis on relance le serveur MySQL

/etc/init.d/mysql restart

Vous pouvez à nouveau vous connecter en root et gérer vos bases.

N.B: Cette manipulation à été testé sur Ubuntu, Debian et Slackware, et, même si le principe reste le même quelque soit la distribution, il peut varier un petit peu ;)

Nombre de visiteurs à partir des logs apache

Régulièrement, il m’arrive de vouloir connaitre le nombre de visiteurs unique qui sont passé la veille sur les sites hébergés sur mon serveur, le tout sans devoir consulter des outils de stats que je n’ai pas forcément à disposition (pas installé, pas autorisé …).

Voici donc un petit script qui va calculer tout ca directement à partir des logs Apache.

Pour infos, la plupart de mes logs Apache sont sous le format suivant (il est important de connaître son LogFormat pour bien ajuster le script) :

"%V %h %{PHPSESSID}C %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

Et le petit script qui va calculer le nombre de visiteurs uniques pour le LogFormat ci-dessus et en prenant les fichiers de logs placé dans « /var/www/ » et nommé avec le nom du domaine :

#!/bin/sh
for k in `ls /var/www/*.log.1`; do
     domaine=`echo $k | cut -f4 -d'/' | sed 's/.log.1//g'`
     nbr=`cat $k | cut -f2 -d' ' | sort -n | uniq | wc -l`
     len=`echo $domaine | wc -c`
     if [ $len -gt 16 ]; then
         tab="\t\t"
     else
         tab="\t\t\t"
     fi
     echo "$domaine$tab$nbr"
done

Ce qui donne :

domaine.net			347
domaine.com			283
blog.domaine.net		1301
www.domaine.fr			705

LogFormat personnalisé & variable PHP

Si vous aimez analyser vos logs Apache pour faire des statistiques personnelles, il est toujours intéressant de pouvoir customiser le format de ses logs. Personnellement, je spécifie des format de logs dans « /etc/apache/conf.d/logformat » avec la syntaxe suivante :

LogFormat "%V %h %{forum_username}C %{PHPSESSID}C %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" forum
LogFormat "%V %h %{user_id}n %{PHPSESSID}C %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" site

Dans le premier cas, je précise 2 variables venant des cookies, on le remarque avec le « C » placé après la variable.

Dans le second exemple, j’utilise une variable provenant d’un cookie mais aussi de mon environnement avec « %{user_id}n ». Le petit « n » placé à la fin signifie que la valeur provient de l’utilisation d’un apache_note()

Dans mon code, je définis simplement :

apache_note('user_id', $monUserId);

J’utilise beaucoup cette technique afin d’obtenir des stats très précise sur mes visiteurs mais aussi d’effectuer des analyses afin d’enrechir un CRM par exemple.

Il suffit par la suite dans son fichier de configuration Apache de placer la directive suivante :

CustomLog /var/www/forum.domaine.net.log forum

Voilà, en espérant que ces petites astuces vous servent par la suite ;)

Problématique

Il me fallait stocker le résultat d’une question à choix multiple sans pour autant avoir à manipuler ensuite ses résultats autrement que par simple visualisation. Du coup, je voulais éviter d’avoir à créer une table pour stocker ces réponses et une table d’association avec ma table miroir de mon formulaire.

C’est là où le type array intervient. Rien de compliqué en fait, il ne fait que simplifier un traitement tout bête qui consiste à stocker un tableau php en base après sérialisation. Et qui le désérialise quand on le récupère depuis un enregistrement de la base.
Une chose de moins à faire en fait et c’est bien là ce qu’on recherche nous autres développeurs, en faire le moins possible ;)

La solution codée

Niveau code, c’est très simple. On défini notre champ dans notre schema.yml comme n’importe quel autre champ

meschoix: { type: array(1000) }

Qui donnera un champ text en mysql.

Ensuite, il suffit de modifier le formulaire obtenu pour transformer notre champ en liste de checkbox de manière très classique:

$this->widgetSchema['meschoix'] = new sfWidgetFormChoice(array(
      'choices' => array(
        '0' => 'Choix1',
        '1' => 'Choix2',
        '2' => 'Choix3',
        '3' => 'Choix4'
      ),
      'multiple' => true,
      'expanded' => true
    ));

Et puis c’est tout! Maintenant, lors de l’enregistrement, Doctrine va sérialiser le résultat de votre sélection et le stocker en base. Et quand vous peuplerez votre formulaire avec des données en base, il le désérialisera et donnera les bonnes valeurs à notre liste de checkbox.

Bien sûr, ca nous oblige à ne pas changer l’ordre des questions et les rend difficilement modifiables. Mais c’est une décision qui doit être prise en connaissance de cette limitation.

Crédit photo: http://www.flickr.com/photos/40491122@N03/3738306829/

Le modèle MVC

Le fameux Modèle Vue Controlleur. Si vous vous dites qu’à part avec un test fonctionnel (c’est à dire un test qui simule le comportement utilisateur via des clicks, avec un sfBrowser ou Selenium) ça va pas être possible de tester votre appli, c’est surement vrai ; que les tests fonctionnels ça se fait vers la fin de l’écriture de votre module, quand votre code HTML bouge plus trop c’est vrai aussi ; et que donc dans le coup vous voyez pas trop comment tester votre application avant de l’avoir finie, c’est vrai aussi.

Du M dans le C

Mais si vous vous dites tout ça, c’est qu’il y a du M dans le C. C’est à dire qu’il y a des parties de votre Modèle dans votre Controlleur et dans le coup, vous ne pouvez tester votre modèle sans votre Controlleur (et dans le coup sans la Vue aussi). C’est typiquement le cas quand vous faites quelque chose comme ça :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$titi)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Faites pas style c’est pas vous, je vous ai vu. Pourquoi ne pas faire ça dans l’action :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->getObjectsByTiti($titi);
  }

et ça dans la classe ObjectTable :

  public function getObjectsByTiti($titi)
  {
	return Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$toto)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Vous serez d’accord avec moi que le résultat est le même mais que c’est un peu plus découplé. On pourra reparler plus tard du fait que le summum serait de retourner un tableau (le fameux HYDRATE_ARRAY de Doctrine passé à la requête) dans la méthode getObjectsByTiti afin de ne pas se retrouver avec quelque chose dépendant de dépendant de l’ORM dans le controlleur (ici une Doctrine_Collection), mais ce n’est pas le sujet ici ;-)

Si c’est pareil, pourquoi c’est mieux alors ?

Parce que je vous le dis ! Oui bon d’accord. Plusieurs avantages, vous n’avez qu’un endroit à aller voir en cas de souci de logique métier : le Modèle. Mais surtout plus vous en mettrez dans le modèle (le premier que je vois écrire du HTML dans le modèle devra coder avec Wordpad), plus vous pourrez en tester ! Et plus vous écrirez de tests unitaires pour vos modèles, plus vous serez confiant dans votre code et plus votre code sera de qualité. Vos controlleurs devraient faire environ 10 lines de code, pas plus. Essayez de vous y tenir, ça vous changera la vie (mettez ce qui concerne la sessions dans votre classe myUser par exemple).

Maintenant nous pourrions écrire un test unitaire du style :

$t->ok(
  count(Doctrine::getTable('Object')->getObjectsByTiti('mogito'))>4,
  '-> Getting object by mogito returns more than 4 objects');

Ici je teste que notre méthode retourne au moins 4 objets si je lui demande un mogito.

Vers la rédemption

Si vous faites bien attention de ne pas avoir de M dans le C, vous pourrez coder toute votre logique applicative sans ouvrir un seul navigateur internet, et c’est même ce que vous devrez vous forcer à faire. Vous pouvez, voire même devez, faire marcher votre logique métier sans la moindre page web, juste en faisant tourner vos tests unitaires qui sont suffisants (et nécessaires) pour voir si votre code est bon et fait ce qu’il doit faire.

En faisant ça, vous pourrez ne vous concentrer que sur le modèle, sur le coeur de la logique métier, sans être parasité par des besoins webs (que le formulaire soit valide pour pouvoir récupérer l’objet, c’est pas le problème du modèle ça !).

Une fois que vous aurez les principales fonctions métier de codées dans votre modèle vous pourrez ensuite écrire vos controlleurs et pages web et à la fin les tests fonctionnels. Mais avant de faire ça, vous saurez qu’il y aura déjà une bonne partie de votre code qui sera écrit et testé.

Et après ?

Quand vous aurez pris l’habitude d’écrire des tests unitaires et que vous en serez devenu accrocs, vous pourrez passer au développement guidé par les tests (le TDD). Là vous écrivez avant les tests (donc en gros ce que vous attendez de votre modèle) et ensuite vous écrivez le modèle : vous serez assuré que tout votre modèle est couvert par les tests, et vous aurez écrit ce que doit faire votre modèle avant de l’avoir implémenté (c’est toujours bien de réfléchir avant de coder, sisi).

Quand vos tests commencerons à prendre du temps à s’exécuter, vous commencerez à vous intéresser à des outils d’intégration continue comme phpUnderControl ou Hudson, dont NiKo a récemment décrit l’intégration avec symfony dans un de ses articles.

Pour finir, en effet ça va vous demander plus de temps de réaliser votre application web en écrivant des tests unitaires. Comme vous êtes Freelance et que le temps c’est de l’argent, vous vous dites que vous ne le ferez pas. Oui mais quand vous aurez livré et que le client reviendra 10 fois vers vous ensuite à cause de bugs, ou que vous aurez changé quelque chose qui aura tout cassé sans que vous ne vous en rendiez compte, et que ça commencera à se savoir que ce que vous faites est buggé : vous penserez fortement à une méthode qui vous permettra d’être beaucoup plus confiant dans votre code, à savoir l’écriture de tests !

Si vous êtes stagiaire ça marche aussi pour prendre de bonnes habitudes et ne pas vous faire taper dessus par votre supérieur, si vous êtes salarié reportez vous au cas du stagiaire ;-)

Je me suis donc dis que j’allais tout simplement le benchmarker grosso modo, afin d’avoir une idée du gain qu’on peut avoir à passer par des tableaux. Car en fait, on sait très bien que le 2e est plus rapide, mais la question, c’est de combien.

J’ai donc pris un modèle assez classique. Un couple de Departement/Region de France.

Dans mon fichier Table de mes départements, je rajoute la méthode suivante pour faire ma jointure sur régions

public function getAll()
  {
    return $this->createQuery('d')
      ->leftJoin('d.Regions r');
  }

Hydratation en objet

Parfait, maintenant, je crée une action qui récupère seulement tous les items de ma table, soit environ 100 départements, en relation avec une région chacun.

public function executeIndex(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute();
  }

Ca reste un cas tout a fait commun. J’ai donc lancé un ab, un programme livré avec apache qui permet de lancer l’exécution d’une page web, n fois avec n requêtes concurrentielles. j’ai décidé de le lancer 100 fois avec 10 requêtes à la fois. Et voici le résultat:

Document Path:          /hydrate/index
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:  16.862 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    5.93 [#/sec] (mean)
Time per request:       1686.205 [ms] (mean)
Time per request:       168.621 [ms] (mean, across all concurrent requests)
Transfer rate:          15.60 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       4
Processing:  1172 1665 167.3   1662    2337
Waiting:     1172 1663 166.5   1661    2337
Total:       1172 1665 167.4   1662    2338
 
Percentage of the requests served within a certain time (ms)
  50%   1662
  66%   1709
  75%   1750
  80%   1783
  90%   1860
  95%   1928
  98%   2102
  99%   2338
 100%   2338 (longest request)

Hydratation en tableau

2e action, le même code, le même résultat HTML souhaité, mais on passe dans le execute le fameux paramètre. Notre résultat ne sera donc plus une Doctrine_Collection, mais un tableau associatif avec en clé, les noms des champs.

  public function executeIndex2(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute(array(),Doctrine::HYDRATE_ARRAY);
  }

Et voici le résultat

Document Path:          /hydrate/index2
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:   10.086 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    9.92 [#/sec] (mean)
Time per request:       1008.569 [ms] (mean)
Time per request:       100.857 [ms] (mean, across all concurrent requests)
Transfer rate:          26.09 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.4      0       6
Processing:   598  992 112.9   1003    1239
Waiting:      598  991 113.0   1002    1239
Total:        599  993 113.0   1003    1239
 
Percentage of the requests served within a certain time (ms)
  50%   1003
  66%   1051
  75%   1081
  80%   1085
  90%   1104
  95%   1128
  98%   1149
  99%   1239
 100%   1239 (longest request)

Bilan

Alors évidemment, il faut prendre en compte la différence de temps de réponse qu’on peut avoir entre 2 lancement de ab. Mais l’objectif est surtout de montrer que le gain est non négligeable et vraiment réel.

On constate que le HTML reçu est bien le même. On a donc le même rendu!
Et côté performance, le 1er cas nous donne une requête en 1,7sec quand le 2e nous donne 1s soit près de 60% de mieux.

Conclusion, quand on souhaite réaliser seulement de l’affichage de données, il faut hydrater en tableau! Même si dans le cas présent, on parle de 0,7sec, il faut voir que c’est un projet vierge avec rien d’autre autour. Le gain est donc bien réel et pas seulement gadget.

Crédit photo: http://www.flickr.com/photos/don3rdse/3208161023/

Pour bien configurer un serveur, il existe plusieurs façons, chaque administrateur ayant la plupart du temps sa propre conf en fonction de ses habitudes et celles de ses users.

Je vous propose ici quelques petits tips à mettre en place sur votre serveur pour voir un peu se qui s’y passe.

Connexion SSH

Il est toujours intéressant de connaître les connexions ssh des utilisateurs sur votre serveur, que ce soit pour des statistiques ou tout simplement surveiller les différentes connexions pour par exemple intervenir rapidement en cas d’intrusion.

Pour cela, il existe un moyen très simple avec l’utilisation de sshrc. Dans le man, il est dit :

/etc/ssh/sshrc
Commands in this file are executed by ssh when the user logs in,
just before the user's shell (or command) is started.
See the sshd(8) manual page for more information.

Nous allons donc y introduire un petit bout de script qui enverra un mail automatiquement.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
IP=`echo $SSH_CONNECTION | awk '{print $1}'`
REVERSE=`dig -x $IP +short`
 
# Message + envoi du mail
echo "USER : $USER
IP : $IP
ReverseDNS : $REVERSE
Date : $DATE
 
" | mail -s "[SSH] $DATE - Connexion de $USER" your_email@domaine.com

A chaque connexion ssh d’un utilisateur, vous recevrez un mail contenant diverses informations. Je souligne au passage qu’un authentification ssh par clef est toujours plus sûre ;)

Modifications de fichiers

Il existe plusieurs applications (plus ou moins performantes) permettant de voir les fichiers modifiés sur votre serveur. Ici, un petit script tout bête qui va vous permette de voir les modifications effectuées depuis X jours sur votre serveur dans un ou plusieurs répertoires donnés.

Bien entendu c’est une surveillance basique, rien de comparable avec un contrôleur d’intégrité (tripwire par exemple), mais cela peut s’avérer très pratique, notamment pour retrouver rapidement une erreur faite dans un script après une modification, mais aussi pour vérifier qu’aucune modification externe n’est faite sur des fichiers sensibles.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
LAPS=1
INFOS="Liste des fichiers modifiés :\n"
for i in `find /etc/ -mtime -$LAPS` `find /home/user/ -mtime -$LAPS`; do
        if [ -f $i ]; then
                INFOS="$INFOS\n$i"
        fi;
done
echo $INFOS | mail -s "[MODIF] $DATE - Fichiers modifies" your_email@domaine.com

N.B : Une vérification est faite pour n’avoir que les fichiers et non les répertoires + fichiers.

Dans l’instruction for i in … ; do vous pouvez mettre plusieurs répertoire en utilisant `find /rep/ -mtime -$LAPS`.

Une fois le script créé, il vous suffit de mettre en place un cron (ici à 23h59 tous les jours) qui le lancera automatiquement et vous avertira par mail des changements.

59 23 * * * /path/to/your/script

Consommation de bande passante

Savoir qui consomme le plus de bande passante sur un serveur est souvent très intéressant, je vous propose donc ici un petit script qui va vous permettre de recevoir par mail les informations concernant les hôtes qui consomment le plus de bande passante, ici sur les 10000 derniers paquets.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
tcpdump -c 10000 -ni eth0 | perl -lane 'END{@keys=sort{$h{$a}  <=> $h{$b}} keys %h;for(reverse(@keys)){printf("%32s => %i\n", $_, $h{$_}) if($h{$_}>100);}} $h{$F[1]}++;' | mail -s "[BP] $DATE - Consommation bande passante" your_email@domaine.com

A noter que pour faire plaisir à Vincent, j’ai utilisé du perl et non du python ^^

Une fois le script en place, un petit ajout dans le cron et c’est partit. Vous pouvez le faire tourner autant de fois que vous voulez, cela dépend surtout du traffic de votre serveur, ici 4 fois par jour soit toutes les 6 heures.

* */6 * * * /path/to/your/script

Voilà, si cela vous intéresse, il y aura surement d’autres tips à venir et surtout n’hésitez pas à demander si vous cherchez un petit truc particulier ou si vous avez des remarques.

Rien à dire, en plus de ne pas être écologique, on a du mal à y voir un intérêt, pauvres humains que nous sommes. Mais quand vient le moment d’écrire son adresse mail sur un site web qui sera visible par tout le monde, on en tremblerait presque.

Du coup, il existe beaucoup de techniques, l’idéal étant encore de ne pas écrire son adresse mail en toutes lettres sur son site! Mais des fois, cela reste bien pratique. Voici donc une solution très simple à mettre en place, qui sans être parfaite, assure quand même le boulot dans la majorité des cas.

A noter que cette technique est tiré du site de Symfony himself. Comme je ne l’avais jamais croisé auparavant, ca peut valoir le coup d’en parler un peu.

Le principe est simpliste mais bien pensé.

On écrit, notre adresse mail à l’envers en PHP (ou tout autre langage serveur on est d’accord) et on demande à notre CSS de l’afficher à l’envers également. Et vous l’aurez compris, l’envers de l’envers, et bien… c’est l’endroit! Fou je vous l’accorde.

En terme de code, voilà ce que ca donnera schématiquement:

<span class="reverse">
 <?php echo strrev('monmail@monadresse.com') // qui va écrire moc.esserdanom@liamnom du coup ?>
</span>

Il suffit maintenant de changer la direction de lecture de notre span reverse via CSS:

span.reverse {
direction:rtl;
unicode-bidi:bidi-override;
}

Et voilà, notre adresse est maintenant lisible à l’endroit à tout le monde bénéficiant d’un support CSS, donc en théorie, tout le monde sauf, les vilains méchants robots spammeurs. Malheureusement ça reste de la théorie mais en pratique, cela reste un manque niveau accessibilité, tout comme on est pas sûr que les robots ne sauront pas interpréter le CSS très bientôt. Mais je pense que ca reste une solution à connaitre.

Mais smushit n’est pas mort, Yahoo l’a juste intégré dans son très bon Yslow. On peut se demander si niveau marketing, c’est une bonne idée, tant Yslow est déjà très complet. Mais je vais laisser cette analyse aux spécialistes. Pour ma part, je vais me contenter de vous montrer comment on s’en sert maintenant. Parce que même si les alternatives existent, je l’aime bien moi ce Smushit!

Première étape, il faut déjà retrouver l’option dans l’armada Yahoo:

Il faut donc aller sur l’onglet Tools et vous aurez accès en bas à l’option All Smush.it. Un simple clic et on vous envoie vers une nouvelle url où vous aurez accès à toutes les images de la page courante smushé!

Oui rien de bien compliqué, mais ca méritait d’être dit selon moi ;)