Votre architecture réseau ne regarde pas vos correspondants, cependant vous avez donné aux plus curieux d’entre eux quelques bribes d’information à votre insu : ip interne, dns interne, chaîne de mta…
Nous allons voir un exemple récent, déterminer quels logiciels font les pies et finir par quelques réglages de ces derniers.
OpenVZ est un système de virtualisation particulier. Il permet de faire tourner de multiples machines virtuelles partageant un seul kernel patché spécialement pour l’occasion. Cette techniques est donc limités à des machines (hôte ou invité) tournant sous linux. En contrepartie les performances sont particulièrement élevés. Il est également très aisé de modifier les particularités physiques des machines virtuelles sans les redémarrer. Cette technique est souvent employée chez les hébergeurs pour les offres « VPS ».
En pratique, c’est utile à des fins de sécurité. On essaie de mettre un seul serveur par VPS (serveur web sur un VPS, MySQL sur un autre, mail encore sur un autre …). Si l’un des serveurs possède une faille de sécurité, les autres serveurs ne pourront alors pas être impactés. Il y a également la facilité à backuper une machine virtuelle et donc au besoin de la dupliquer ou la déplacer. Cependant, on ne peut pas faire de migration à chaud comme certains de ses concurrents.
La création d’une machine ne prend guère plus d’une minute sur une machine correcte, ce qui permet de s’en servir comme d’un moyen de tester des logiciels sans encombrer votre distro. Qui plus est, le lancement d’une machine est quasi instantané, ce qui peut parfois sauver des manchots…
Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)
Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.
Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).
Ras le bol de voir des tentatives de connexion sur votre SSH ? Il existe plusieurs logiciel pour vous en prémunir avec en tête de liste le célèbre Fail2ban qui permet de protéger SSH ainsi que la plupart des autres serveurs logguant l’authentification. Mais alors pourquoi choisir DenyHosts ? DenyHosts se limite à la protection SSH mais sa force provient de deux fonctionnalités : utiliser un système de synchronisation entre plusieurs DenyHosts ( je ne l’aborde pas ), mais également le partage des IP incriminées. Afin de récupérer des IP à blacklister et de d’offrir les siennes afin de se fabriquer une blacklist évolutive.
Un attaquant vera son adresse IP inscrite dans le fichier /etc/hosts.deny l’empêchant de se logguer.
Ça semble évident : dans le monde de l’OpenSource, de la programmation ou de l’informatique en général, s’il est un besoin omniprésent, c’est bien celui de structurer une pensée, schématiser une procédure, ou hierarchiser un projet.
Combien de projets sont-ils morts ou ont-ils été paralysés par un défaut de structure, d’ordre et de clarté dans la manière de procéder ?
Freemind, ce n’est pas un nouveau procédé de méditation New-Age à la mode, mais c’est tout de même la solution à ce problème !
Vous vous souvenez dans l’article : http://geekfault.org/2009/12/31/construire-sa-gateway-from-scratch/ Je vous ai parlé de plein de petits ajouts afin de rendre votre eeegw MUST.
Je vous avais parlé de :
Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante.
Finalement j’ai trouvé le soft parfait pour faire ça : http://www.pps.jussieu.fr/~jch/software/polipo/
