Evolix organise une formation administration Linux orientée LAMP (Linux Apache MySQL PHP) [3 Jours - 18h] dans ses locaux au Pôle Média Belle de Mai les 29, 30 et 31 Mars prochain.
Plan de formation
N’hésitez pas à demander plus de renseignements !

Bravo à l’équipe informatique d’Exotismes pour avoir été les plus proches des réponses officielles !!

Pour vous curieux, les réponses attendues étaient :

Photo 1er semestre :
+43° 12′ 49.84″, +5° 21′ 36.91″
(43.213845,5.360252)
Alias près de Callelongue, Les Goudes / Rocher Saint-Michel pas loin de la grotte du Puit (face nord)

Photo second semestre :
+43°11′59.23″, +5°33′8.47″
(43.199788,5.552355)
La photo a été prise à proximité de la Route des crêtes

La fin du support officiel de Debian Etch approchant, il est grand temps de migrer vers Lenny pour les machines pas encore à jour. Après un premier exemple de migration Debian Etch->Lenny, je poursuis la série avec des informations tirées de plusieurs migrations récentes sur des serveurs en production.

Je ne rappellerais pas toutes les précautions nécessaires (tests préalables, sauvegardes, désactivations des services, etc.) ni la classique question  sur  “quand faut-il migrer ?”, vous trouverez tout cela dans mes exemples précédents. Je rappelle simplement l’idée de base : prendre les précieuses Release Notes, mettre à jour le fichier sources.list, puis exécuter les commandes aptitude update && aptitude upgradex, puis mettre-à-jour les services les plus critiques via aptitude install <PACKAGE>, et enfin aptitude dist-upgrade && aptitude dist-upgrade (répéter dist-upgrade est souvent nécessaire).

Passons désormais aux différentes remarques sur ces migrations :

- PostgreSQL : on passe de la version 8.1 à 8.3. Notez qu’il s’agit de paquets différents, il est donc possible de garder la version 8.1 en Etch, et d’installer en parallèle la version 8.3, afin de faciliter encore plus la migration. Pour migrer les données, on réalisera un dump avec pg_dumpall qui sera réinjecté dans la nouvelle base. On pourra ensuite adapter le port dans postgresql.conf pour passer la version 8.3 en production.

- phpPgAdmin : avec PostgreSQL 8.3, on ne peut plus se connecter à la table template1 : c’est le comportement par défaut de phpPgAdmin, qu’on devra donc modifier en mettant postgres à la place (pour la variable $conf['servers'][0]['defaultdb'] dans le fichier config.inc.php)

- Apache : la configuration de l’alias /icons/ est déplacé dans le fichier mods-available/alias.conf, il peut donc faire doublon avec la déclaration dans apache2.conf, ce qui sera signalé via le warning suivant : [warn] The Alias directive in /etc/apache2/apache2.conf at line 240 will probably never match because it overlaps an earlier Alias. Commenter les directives dans le fichier apache2.conf résoudra ce petit soucis.

- OpenLDAP : on passe d’une version 2.3 à 2.4, mais le plus marquant pour la migration est que cela force le processus à tourner avec un utilisateur/groupe dédié. Pour diverses raisons (dist-upgrade interrompu par exemple), on pourra rencontrer des soucis plus ou moins alarmants. Ainsi, j’ai pu rencontrer cette erreur :
bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
bdb_db_open: database “dc=example,dc=com” cannot be opened, err -30978. Restore from backup!
backend_startup_one: bi_db_open failed! (-30978)
slap_startup failed
On veillera donc sur l’utilisateur/groupe propriétaire des fichiers dans le répertoire /var/lib/ldap et, au besoin, on ajustera : chown -R openldap:openldap /var/lib/ldap/
Mon conseil : mettre-à-jour le paquet slapd de façon spécifique avant le dist-upgrade

- Postfix : on passe de 2.3 à 2.5. On notera simplement la valeur par défaut de $smtp_line_length_limit characters qui passe à 990, ce qui coupe les lignes trop longues pour se conformer au standard SMTP. Si cela posait problème, on pourrait revenir à l’ancien comportement en positionnant smtp_line_length_limit=0

- SpamAssassin : l’utilisant en stockant la configuration des utilisateurs dans un annuaire LDAP, le daemon spamd s’est mis à râler : cannot use –ldap-config without -u
Le problème sera résolu en ajoutant l’option -u nobody, ce qui fera tourner spamd en tant que nobody (ce qui n’est pas une mauvaise chose, au contraire).

- Amavis : apparemment, lors de la détection d’un virus, le code retourné n’est plus 2.7.1 mais 2.7.0 : 2.7.0 Ok, discarded, id=13735-07 – VIRUS: Eicar-Test-Signature
Rien de bien grave, mais cela a nécessité d’adapter un plugin Nagios pour qu’il attende le bon code de retour.

- Courier-imapd-ssl : après une mise-à-jour gardant mon fichier /etc/courier/imapd-ssl actuel, j’obtenai des erreurs avec certains clients IMAP :
couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
En regardant de plus près, certaines directives changent dans ce fichier de configuration, et il est donc conseillé de repartir du fichier proposé par Lenny, et d’y apporter ses modifications (souvent, cela se limite à préciser le certificat).

- Horde : si vous utilisez une base de données pour stocker les paramètres ou autres, la paquet php-db (déjà en Recommends: en Etch) est d’autant plus nécessaire, sous peine d’obtenir l’erreur : PHP Fatal error:  _init() [<a href='function.require'>function.require</a>]: Failed opening required ‘DB.php’ (include_path=’/usr/share/horde3/lib:.:/usr/share/php:/usr/share/pear’) in /usr/share/horde3/lib/Horde/DataTree/sql.php on line 1877

- Sympa : on attaque là le cauchemard de mes migrations. À chaque fois, tellement de soucis majeurs et mineurs, que j’ai l’impression d’être le seul à utiliser ce paquet. Voici en vrac tous les soucis rencontrés : les accents dans les descriptions ont sautés (une sorte de double encodage) et cela a nécessité des corrections manuelles, la table logs_table doit être créée à la main (j’utilise Sympa avec PostgreSQL), et enfin une typo surprenante un “GROUP BY” à la place d’un “ORDER BY” (j’ai ouvert le bug #566252 à ce sujet).

- Asterisk : on passe de la version 1.2 à la version 1.4. Lors de la migration, j’ai constaté un bug étrange, le fichier modules.conf qui charge les modules additionnels a disparu. Du coup, sans lui, Asterisk ne charge pas les modules nécessaires (SIP, etc.). Il a donc fallu le restaurer.

- udev : le meilleur ami des sysadmins (ou pas). Si les migrations douloureuses Sarge->Etch sont loin derrière nous, il reste néanmoins quelques blagues. La dernière en date a été un renommage des interfaces réseau : eth0->eth1 et eth1->eth2. Classique mais étonnant, ce genre d’humour est sensé être dépassé grâce aux “persistent rules” qui nomment les interfaces en fonction de l’adresse MAC. À rester vigilant sur ce point avant le redémarrage donc.

Voilà pour les remarques. Vous noterez que je n’ai pas abordé le noyau Linux. C’est parce que pour la majorité de nos serveurs, ils sont gérés de façons spécifiques (au lieu d’utiliser les noyaux officiels Debian). Ainsi, ils restent dans leur version actuelle (2.6.31 à cette heure) pendant la migration. Bien sûr, cela n’empêche pas d’effectuer un redémarrage de la machine suite à la mise-à-jour : cela permet de s’assurer que tout est bien en place et le sera toujours après un éventuel redémarrage d’urgence.

Rendez-vous pour de prochaines migrations !

Cette année, pour souhaiter à tous ses clients une excellente année, Evolix va leur faire parvenir avec ses meilleurs voeux de jolis calendriers format bureau avec une image différente par semestre d’un paysage typiquement marseillais.
Un jeu concours va peut-être être ouvert sur le lieu précis où ces photos ont été prises par un intrépide membre d’Evolix !

Meilleurs voeux à tous !

ps : les envois débutent cette semaine, soyez patients !

Introduction

J'ai eu récemment l'occasion de mettre en oeuvre une infrastructure LAMP, reposant sur la plate-forme d'hébergement de machines virtuelles d'Amazon, nommé EC2, pour Elastic Compute Cloud.

Le principe de fonctionnement est le suivant : on créé une image AMI (Amazon Machine Image), contenant le système de fichiers du système d'exploitation à démarrer. Il est possible d'utiliser et de personnaliser des AMI fournis par Amazon, ou de la créér de zéro. Le noyau, quant à lui, est à sélectionner parmi ceux proposés par Amazon.

Ensuite, cette image est téléchargée vers l'infrastructure de stockage d'Amazon, S3 (Simple Storage Service). Après enregistrement de celle-ci, elle peut être instanciée en une ou plusieurs machines virtuelles.

Une particularité de cette solution est que les données stockées dans le système de fichiers racine des machines virtuelles ne sont pas persistantes. Une fois une instance terminée (via la commande halt par exemple, ou via l'interface d'Amazon), celles-ci sont perdues ! Il faut alors utiliser pour les données applicatives une autre fonctionnalité d'Amazon, les EBS (Elastic Block Storage). Il s'agit de disques virtuels que l'on peut ajouter à une instance, accessibles sous forme de simples block devices que l'on peut formater et monter. A noter que depuis peu il est possible d'utiliser un EBS en tant que système de fichiers racine, ce qui permet de démarrer et d'arrêter une machine à volonté, sans nécessité d'instancier à nouveau une AMI.

Mise en oeuvre

Ce premier article décrit les étapes à suivre pour créér sa propre image AMI de Debian 5.0, l'envoyer vers Amazon, et la démarrer. Il vous faudra évidemment pour cela un compte Amazon Web Services.

Création de l'image

Création d'une image d'une taille de 1 Go et montage sous /mnt/ami :

# EC2_AMI_NAME=debian50
# dd if=/dev/zero of=$EC2_AMI_NAME.img bs=1M count=1024
# mkfs.ext3 -F $EC2_AMI_NAME.img
# mkdir /mnt/ami
# mount -o loop $EC2_AMI_NAME.img /mnt/ami

Installation et exécution de l'outil debootstrap, qui permet le téléchargement et l'installation d'un système Debian de base dans le point de montage. Attention, une architecture 32 bits est requise pour pouvoir démarrer des instances de type Small.

# aptitude update
# aptitude install debootstrap
# debootstrap --arch i386 lenny /mnt/ami

Montage des pseudo systèmes de fichier :

# mount -t proc proc /mnt/ami/proc/
# mount -t devpts devpts /mnt/ami/dev/pts/

Changement du répertoire racine vers le point de montage (chroot) et installation des packages nécessaires :

# chroot /mnt/ami
# aptitude install udev libc6-xen ssh

Configuration des points de montage dans /etc/fstab tel que recommandé dans la documentation :

/dev/sda1  /         ext3    defaults        1 1
NONE       /dev/pts  devpts  gid=5,mode=620  0 0
none       /dev/shm  tmpfs   defaults        0 0
none       /proc     proc    defaults        0 0
none       /sys      sysfs   defaults        0 0
/dev/sda2  /mnt      ext3    defaults        0 0
/dev/sda3  swap      swap    defaults        0 0

Ajout des lignes suivantes au fichier /etc/network/interfaces pour configurer l'interface eth0 en DHCP :

auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp

Il est également nécessaire d'ajouter sa clé SSH dans /root/.ssh/authorized_keys, ou de définir un mot de passe pour le compte root.

Enfin, quitter le chroot, et démonter l'image :

# /etc/init.d/ssh stop
# exit
# umount /mnt/ami

Génération de l'image AMI

Pour la suite des opérations, il est nécessaire de télécharger et décompresser les Amazon EC2 API Tools et Amazon EC2 AMI Tools. On installe également les dépendances nécessaires.

# aptitude install ruby libopenssl-ruby unzip sun-java6-jre
# EC2_AMI_TOOLS=ec2-ami-tools-1.3-XXXXX
# EC2_API_TOOLS=ec2-api-tools-1.3-XXXXX

Il faut également générer une clé et un certificat X.509, et faire pointer les variables d'environnements ci-dessous vers les fichiers téléchargés. Ceux-ci seront utilisés pour effectuer des requêtes vers les web services d'Amazon.

# EC2_PRIVATE_KEY=pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem
# EC2_CERT=cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem

Enfin, noter son EC2 user ID, généralement visible en haut à droite des pages d'AWS.

# EC2_USER_ID=XXXX-XXXX-XXXX

Création de l'image AMI :

# export EC2_HOME=$EC2_AMI_TOOLS
# $EC2_AMI_TOOLS/bin/ec2-bundle-image -i $EC2_AMI_NAME.img \
    -k $EC2_PRIVATE_KEY -c $EC2_CERT -u $EC2_USER_ID -r i386

Upload sur S3

Il faut maintenant télécharger l'image vers Amazon S3. Pour cela, il est nécessaire de récupérer son Access Key ID et sa Secret Access Key sur la page Security Credentials. Il faut également sélectionner la région où sera localisée l'instance (US ou EU), ainsi que la bucket S3 où sera stockée l'AMI.

# EC2_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX
# EC2_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# EC2_REGION=EU
# EC2_BUCKET=XXXXXXXX
# $EC2_AMI_TOOLS/bin/ec2-upload-bundle -m /tmp/$EC2_AMI_NAME.img.manifest.xml \
    -a $EC2_ACCESS_KEY -s $EC2_SECRET_KEY -b $EC2_BUCKET \
    --location $EC2_REGION

Enregistrement de l'instance

Il est nécessaire de déclarer l'image à Amazon pour pouvoir l'instancier. L'option --url est nécessaire pour préciser que l'on s'adresse à la région Europe d'EC2.

# export EC2_HOME=$EC2_API_TOOLS
# export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.12
# $EC2_API_TOOLS/bin/ec2-register \
     --url http://eu-west-1.ec2.amazonaws.com \
     -n $EC2_AMI_NAME \
     $EC2_BUCKET/$EC2_AMI_NAME.img.manifest.xml

La commande retourne l'ID de l'AMI qui vient d'être enregistrée.

Instanciation

L'instanciation peut également se faire via une requête sur AWS :

# EC2_AMI_INSTANCE_ID=ami-XXXXXXXX
# EC2_AKI=aki-7e0d250a
# EC2_RAMDISK=ari-7d0d2509
# $EC2_API_TOOLS/bin/ec2-run-instances $EC2_AMI_INSTANCE_ID \
     -K $EC2_PRIVATE_KEY \
     -C $EC2_CERT \
     --kernel $EC2_AKI --ramdisk $EC2_RAMDISK \
     --region eu-west-1

Le noyau utilisé (aki-7e0d250a) est un 2.6.21.7-2.fc8xen, suffisamment récent pour l'utilisation de udev. Ce n'est pas le cas du noyau par défaut.

Connexion à la machine

Les instances créées peuvent être listées à l'aide de la commande suivante :

# $EC2_API_TOOLS/bin/ec2-describe-instances -K $EC2_PRIVATE_KEY \
  -C $EC2_CERT --url http://eu-west-1.ec2.amazonaws.com

Parmi les informations obtenues, on peut notamment connaître le nom DNS public de l'instance créé, de la forme ec2-XXX-XXX-XXX-XXX.eu-west-1.compute.amazonaws.com. A noter que ces informations sont également disponibles via l'interface web.

Enfin, il ne reste plus qu'à se connecter avec le compte root à sa nouvelle machine !

À l’occasion d’un petit déjeuner organisé par Evolix, en partenariat avec Libertis, la région PACA, le Prides SCS et le FEDER, dans les locaux de Marseille Innovation au Pôle Média Belle de Mai (oui, c’est un peu long mais je me dois de citer tous les partenaires), j’ai pu animer une présentation sur l’organisation technique du développement web. Vous pouvez télécharger les slides de la présentation (format PDF, 2.2 Mo).

Cette présentation a permis de faire un point sur les différentes organisations en place dans des sociétés clientes ou proches d’Evolix. Je remercie d’ailleurs les responsables techniques qui ont répondu à mes questions ces derniers jours. Globalement, il se dégage une forte tendance à l’utilisation d’Eclipse comme IDE, que ça soit pour les projets en Java ou PHP. Au niveau SCM, on retrouve CVS et majoritairement SVN, avec une gestion des branches plus ou moins avancée. En terme de bugracker, c’est assez divers : Trac, Mantis ou Bugzilla. Pour le développement, c’est souvent http://localhost qui est utilisé. Une mise en préproduction est ensuite effectuée, puis une bascule en production, à l’aide de scripts personnalisés s’appuyant sur le SCM. En terme de méthodes, plusieurs sociétés utilisent des méthodes agiles (tests unitaires, sprints, etc.) de façon plus ou moins avancées. En général, l’organisation en place est informelle et reprend les bonnes idées adaptées à son projet. Les benchmarks et tests de performance sont plutôt effectués dans une seconde phase (en préproduction voire en production), sauf dans certains cas où ils sont intégrés aux tests unitaires (ce qui est une très bonne pratique). Enfin, en terme de framework, on distingue deux tendances : l’exploitation d’un framework existant et reconnu, ou l’utilisation d’un framework développé en interne.

Bien évidemment, ce petit inventaire n’a pas la prétention d’être exhaustif ou de définir une organisation idéale. C’est plutôt un passage en revue de bonnes pratiques, permettant de les découvrir … ou de s’assurer qu’on ne passe pas à côté de certains outils.

Evolix a organisé dans le cadre des petits-déjeuners Libertis en partenariat avec la Région PACA, le Prides SCS et le FEDER un petit déjeuner le 26 Novembre 2009 dans les locaux de Marseille Innovation au Pôle Média Belle de Mai autour du sujet :

Organisation technique du développement web (notion de serveurs de dev/recette/prod, déploiement,outils de gestion du code, bugtrackers, méthodes, etc.)

Les slides de la présentation :
Slides Présentation Petit Déjeuner Evolix 26 Novembre 2009

En partenariat avec :

Evolix était présente sur le SPLLOS 3 (Salon Professionnel des Logiciels Libres et Open Source 3ème édition organisé par Libertis) au sein du TopTIC au Palais de la Bourse de Marseille le 13 Octobre dernier.
J’ai pu pour ma part participer à l’atelier organisé par le CIP (Club Informatique de Provence) sur le sujet de la virtualisation aux côtés notamment du DSI d’Autogrill et du chef des informations du magazine CIO Online. Le screencast de démonstration de “Xen powered by Evolix” a été présenté à la salle en guise de démonstration pratique !

Quelques photos du salon :

Voici un récapitulatif de la mise en place des protocoles d'authentification SMTP DKIM et DomainKeys sous Debian Lenny. Le serveur de mail utilisé est Postfix, mais tout MTA sachant communiquer avec les milter de Sendmail peut normalement être utilisé. La signature et la vérification des messages sera effectuée pour le domaine <domain>. Voici les étapes :

Installation de dkim-filter et dk-filter :

# aptitude install dkim-filter dk-filter

Ajouter dans le fichier /etc/dkim-filter.conf un ensemble de directives indiquant le nom du domaine qui va utiliser DKIM, un nom de selector (exemple : 2009), et le nom du fichier qui contiendra la clé privée utilisée pour la signature. L'utilisation des selector permet notamment de changer et/ou révoquer facilement une clé, ou d'utiliser des clés différentes sur des serveurs de mails différents.

Domain      <domain>
KeyFile     /etc/ssl/dkim_<domain>_<selector>.key
Selector    <selector>

Générer la clé :

# openssl genrsa -out /etc/ssl/private/dkim_<domain>_<selector>.key

Et en extraire la partie publique :

# openssl rsa -in /etc/ssl/private/dkim_<domain>_<selector>.key \
          -pubout -outform PEM

Dans la zone DNS du domaine <domain>, ajouter l'enregistrement suivant. La valeur de <key> correspond à la sortie de la commande précédente, contenue entre les lignes _BEGIN PUBLIC KEY_ et _END PUBLIC KEY_ :

<selector>._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=<key>"

Ajouter les paramètres de démarrage de dkim_filter dans /etc/default/dkim-filter. Le fichier /etc/dkim.hosts contient la liste des serveurs dont les mails sortants seront chiffrés :

SOCKET="inet:2505@localhost"
DAEMON_OPTIONS="-l -i /etc/dkim.hosts"

Les paramètres de dk-filter, dans /etc/default/dk-filter, sont similaires, à l'exception que tout est passé via les options, celui-ci n'utilise pas de fichier de configuration.

DAEMON_OPTS="$DAEMON_OPTS -d <domain>  -S <selector> -i /etc/dkim.hosts \
             -s /etc/ssl/private/dkim_<domain>_<selector>.key"
SOCKET="inet:2506@localhost"

Puis les redémarrer :

# /etc/init.d/dkim-filter start
# /etc/init.d/dk-filter start

Reste enfin à utiliser ces milter au niveau de Postfix, pour cela ajouter les directives suivantes au fichier /etc/postfix/main.cf :

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:2505 inet:localhost:2506

Et redémarrer Postfix :

# /etc/init.d/postfix restart

Un test basique de fonctionnement est alors d'envoyer un mail à destination d'un domaine effectuant des vérifications DKIM, yahoo.com par exemple.

# nc 127.0.0.1 25 <<EOT
HELO localhost
MAIL FROM: root@<domain>
RCPT TO: <account>@yahoo.com
DATA
Subject: Test DKIM
.
QUIT
EOT

Les signatures DKIM et DomainKeys sont correctement vérifiées si l'en-tête Authentication-Results contient dkim=pass et domainkeys=pass.

On peut également envoyer un mail à destination de son domaine, et vérifier que l'en-tête Authentication-Results est bien ajoutée, et valide.

Evolix a organisé le 23 Juillet dernier une soirée autour de deux thèmes :
* la présentation de Git, logiciel Open Source pour la gestion de code source, par Grégory Colpart,
* et la présentation de PHPBoost, CMS Open Source, par son développeur principal Régis Viarre.

Cet apéritif convivial a réuni une douzaine de personnes au sein des bureaux d’Evolix situés au Pôle Média Belle de Mai (13003 Marseille).

Au sujet de PHP Boost

[PDF]Slides de la présentation de Régis Viarre (actuellement en stage au sein d’Evolix) :

PHPBoost est un CMS (Content Managing System ou système de gestion de contenu) français.

Voici quelques unes de ses caractéristiques :
*  Projet Open Source sous licence GNU/GPL
* Code XHTML 1.0 strict et sémantique
* Multilangue
* Facilement personnalisable grâce aux thèmes et templates
* Gestion fine des droits et des groupes multiples pour chaque utilisateur
* Url rewriting
* Installation et mise à jour automatisées des modules et du noyau
* Aide au développement de nouveaux modules grâce au framework de PHPBoost

URL du site officiel : http://www.phpboost.com/

Au sujet de Git

Voici les slides et une courte vidéo de la présentation :

[PDF]Slides
* Introduction à la gestion de code source (définition CVS/SCM, fonctions basiques)
* Présentation de Git (historique, fonctionnement interne, stockage des informations)
* Git en action (exemples, comparaison avec CVS/SVN, les repository, les branches, etc.)

et voici une courte video de la présentation.

À bientôt pour la prochaine présentation thématique Evolix !

Une faille de sécurité sur le logiciel Wordpress permet de réinitialiser le mot de passe d’un utilisateur connu (admin par exemple…). Cela consiste à faire une requête du type http://SERVERNAME/wp-login.php?action=rp&key[]= (soumettre une key[] vide permet apparemment de rendre inutile la vérification par mail). Il est donc conseillé de mettre à jour Wordpress en version 2.8.4 (voici le patch pour passer de la version 2.8.3 à 2.8.4).

J’en profite pour rappeler quelques notions basiques pour sécuriser une installation d’un logiciel PHP, surtout quand il est très répandu : si possible, limiter les accès aux parties backoffice via Apache (restriction par adresses IP et/ou authentification HTTP), utiliser des identifiants originaux (pas forcément admin…), des mots de passes complexes, éviter les modules/plugins non fiables, suivre les notifications de mises-à-jour et les appliquer rapidement (cela implique de limiter les modifications intrusives empêchant des futures mises-à-jour, ou du moins les préparer sous forme de patch pour les ré-appliquer très rapidement), etc. Pour le premier point, voici un exemple de sécurisation de Wordpress via Apache :

<LocationMatch "^/wordpress/wp-(admin|login)">
Deny from all
Allow from YOUR_IP
</LocationMatch>