Iptables – supprimer une règle spécifique
Si comme moi, vous utilisez fail2ban ce qui est une très bonne chose, et que comme moi vous avez oublié de lui dire d'ignorer votre IP ce qui est une mauvaise chose et que par malheur vous vous plantez X fois (chez moi au bout du 2eme fail en 2 heures ==> ban pendant 10 jours !)
pour commencer il faut trouver une autre porte d'entrée au serveur (une autre adresse IP)
en suite le but est de supprimer la règle concernant votre IP sans devoir toucher aux autres règles voici comment faire :
iptables -L --line-numbers |
ce qui donne (entre autre) :
Chain fail2ban-ssh (1 references) num target prot opt source destination 1 DROP all -- kol-static-36-240-16-61.direct.net.in anywhere 2 DROP all -- unknown-host.yaltanet.com.ua anywhere 3 RETURN all -- anywhere anywhere |
là on vois qu'il y a 2 ip bannies, il faut repérer le numéro de ligne de cette qu'on veut supprimer (ce qui revient à autoriser l'ip a se connecter au serveur)
iptables -D fail2ban-ssh X |
fail2ban-ssh : le nom de la chain créée par fail2ban pour le ssh
X : le #numéro de ligne qui nous intéresse
Subversion 1.6 sur Debian lenny
alors là c'est le billet mémo par excellence :)
étant utilisateur occasionnel de tortoiseSVN à jour, impossible pour moi d'utiliser svn en ligne de commande (beaucoup plus rapide que tortoise) sur ma debian, d'où l'idée de d'installer svn 1.6 qui n'est pas disponible dans les paquets debian.
la procédure consiste a utiliser les backports, elle est très simple, encore faut-il la connaitre (ou la trouver facilement)
pour commencer il faut savoir que svn 1.5 doit être déjà installé sur la machine, si ce n'est pas le cas, faire :
apt-get install subversion subversion-tools apache2 libapache2-svn |
1. configuration du sources.list
il faut ajouter cette ligne à la fin du fichier /etc/apt/sources.list
deb http://www.backports.org/debian lenny-backports main contrib non-free |
2. configurer les backports :
wget -O - http://backports.org/debian/archive.key | apt-key add - apt-get update |
3. on instalel svn en spécifiant la source (backports) :
apt-get -t lenny-backports install subversion subversion-tools libapache2-svn |
et maintenant on peut utiliser svn en ligne de commande avec des référentiels "commités" avec des version récentes de subversion (comme tortoise)
Source du tuto : http://swherdman.com/2009/05/subversion-16-on-debian-lenny/
Configuration d’Exim avec nom de domaine géré par gandi
Bonjour,
aujourd'hui nous allons voir comment, facilement, exploiter une fonctionnalité offerte par Gandi (ou bien comprise dans le prix de nom de domaine, ça dépend comment on voit les choses).
beaucoup d'entre nous n'ont pas le temps (et souvent pas l'envie de non plus) de se prendre la tête avec un vrai MTA genre postfix ou exim et le configurer en s'assurant de bien renseigner les enregistrement MX chez le registrar, d'installer les bons outils pour le POP (ou IMAP) etc. etc.
il faut savoir qu'avec un nom de domaine de chez Gandi, on a droit a quelques comptes emails (5 par domaine de mémoire) et une infinité d'alias sur ces comptes.
ce qu'on va voir ici, c'est comment configurer une machine (serveur dédié) pour assurer le minimum syndical en s'appuyant sur le service proposé par gandi.
dans notre exemple il s'agira d'un Exim4 (c'est le seul avec lequel j'ai testé pour l'instant, et ça marche tellement bien que je n'ai pas envie de changer :-) )
on va supposer un compte admin@mon-domaine.com
tout d'abord il faut éditer le fichier : /etc/exim4/passwd.client en ajoutant tout à la fin :
*:admin@mon-domaine.com:MOT-DE-PASSE-DU-COMPTE |
en suite, on va éditer le fichier /etc/exim4/update-exim4.conf.conf pour avoir quelque chose comme :
dc_eximconfig_configtype='satellite' dc_other_hostnames='' dc_local_interfaces='127.0.0.1' dc_readhost='mon-domaine.com' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='mail.gandi.net:587' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' |
un petit
/etc/init.d/exim4 reload |
et le tour est joué :)
votre serveur envoie maintenant ces mails en utilisant le compte gandi, plus de soucis de conf complexe, maj à risque etc a se faire...
pour tester :
test-machine:/etc/exim4# mail user@omain.tld Subject: test ceci est un message de test ! . Cc: |
PS. procédure trouvé il y a un moment sur les forums gandi, mais je n'arrive jamais a la retrouver je la mets ici, au cas où.
PS2. comme d'habitude, notre distribution ici est une Debian :)
Installer et configurer Munin
... sur une debian.
Aujourd'hui on va voir comment installer et configurer l'outil de monitoring munin
Un petit article aide mémoire comme beaucoup d'autres sur ce blog :)
pour commencer :
apt-get install munin munin-node |
en suite il faut éditer le fichier de configuration : /etc/munin/munin.conf
changer juste la valeur de htmldir pour choisir un répertoire où les fichiers html des rapports seront déposés, pour moi c'est sous un vhosts de statistiques, exemple :
htmldir /var/www/munin |
vous pouvez aussi laisser la valeur par défaut.
un autre fichier de configuration pourrait vous intéresser, personnellement je n'ai pas eu a le toucher : /etc/munin/munin-node.conf
Important : Assurez vous que le répertoire "htmldir" choisi plus haut soit accessible en écriture a l'utilisateur munin (sinon le cron vous bombarde de mails pas cool), moi j'ai fait un :
chown -R munin:www-data MON/HTML/DIR/DE/MUNIN |
maintenant on restart tout ça :
/etc/init.d/munin-node restart |
quelques minutes après (le temps de générer quelques stats) on va a l'url correspondant au htmldir et on admire les garphs :)
Lighttpd vs Apache vs Lighttpd + Apache
Il fut un temps où on ne se posait pas de question quant au serveur web, on prend Apache et on en parle plus, aujourd'hui les choses ont changé, Apache reste quand même le plus utilisé avec plus de 66% des parts de marché, suivi par IIS, puis tous les autres "petits" derrière, néanmoins en fonction des besoins, certains de ces petits peuvent s'avérer bien plus performants qu'Apache, aujourd'hui on va tester 3 configurations possibles avec Apache et Lighttpd.
d'après ce qu'on peut lire un peu partout sur le net, Lighttpd (lighty pour les intimes) est beaucoup plus performant quand il s'agit de servir des pages statiques, mais qu'en est-il vraiment ? et comment s'en sort-il avec le contenu dynamique ? (des sites statiques ça n'existe plus de nos jours ^^).
pour notre test, on va prendre un site très léger, basé sur Zend framework (donc loin d'être statique), contenant une page qui affiche 9 images au hasard a partir d'une tables mysql contenant environ 1000 enregistrements (seulement les emplacement des images sont stockés dans la base). Le serveur de test est un kimsufi L (petit processeur et 1Go de RAM).
versions utilisées :
Apache 2.2.9
Lighttpd 1.4.19
PHP 5.2.6
pour les tests on utilise siege, on lance donc un siege avec 100 concurrency sur 10 minutes, voici la commande :
siege -c100 -t10M URL_DU_SITE |
on note également le Load average de la machine a la fin de l'opération.
1ère configuration : Lighttpd tout seul
voici le resultat :
Load average : 4.87 Lifting the server siege... done. Transactions: 23859 hits Availability: 100.00 % Elapsed time: 600.37 secs Data transferred: 83.25 MB Response time: 2.02 secs Transaction rate: 39.74 trans/sec Throughput: 0.14 MB/sec Concurrency: 80.21 Successful transactions: 23859 Failed transactions: 0 Longest transaction: 5.20 Shortest transaction: 0.10 |
2ème configuration : Apache2 tout seul
le résultat :
Load average : 77.51 Lifting the server siege... done. Transactions: 23543 hits Availability: 100.00 % Elapsed time: 599.66 secs Data transferred: 82.16 MB Response time: 2.04 secs Transaction rate: 39.26 trans/sec Throughput: 0.14 MB/sec Concurrency: 80.22 Successful transactions: 23543 Failed transactions: 0 Longest transaction: 10.51 Shortest transaction: 0.05 |
3ème configuration : Lighttpd + Apache
maintenant faisons le test en couplant les 2, dans cette configuration tout ce qui est statique (images, css, js, etc.) sera servi par lighty alors que les scripts php eux, seront traités par apache, pour cela on active le mod_proxy dans lighty, et on ajoute le code suivant dans le vhost de notre site :
$HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm)$" { proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 8080 ) ) ) } |
vous l'aurez compris, Apache écoute sur le port 8080 (c'est fait en changeant le fichier /etc/apache2/ports.conf).
voici le résultat :
Load average : 14.79 Lifting the server siege... done. Transactions: 22684 hits Availability: 100.00 % Elapsed time: 600.25 secs Data transferred: 79.10 MB Response time: 2.13 secs Transaction rate: 37.79 trans/sec Throughput: 0.13 MB/sec Concurrency: 80.53 Successful transactions: 22684 Failed transactions: 0 Longest transaction: 8.61 Shortest transaction: 0.07 |
plutôt surprenant !
Conclusion :
Lighty s'en sort très bien au vu des transactions/s (ou le nombre total de transactions traitées), contrairement a ce qu'on pouvait attendre, coupler les 2 nous fait perdre en performances (on enregistre quand même un load average nettement inférieur a la config d'apache tout seul).
personnellement ce que je retiens, c'est que lighty n'est pas si mauvais que ça pour le contenu dynamique, les performances restent quand très proches dans les 3 cas, donc autant utiliser la solution qui nous plait :-)