ubuntu-fr

Lire un livre sur comment optimiser son site web c'est bien, appliquer les conseils qui s'y trouvent c'est encore mieux. Parmi les 14 bonnes pratiques, 3 peuvent être appliquées très rapidement au niveau système en quelques lignes de commande et de configuration du serveur web pour un résultat quasi immédiat :

• Règle 3 : Ajoutez et configurez l'en-tête Expires
• Règle 4 : Compressez avec gzip
• Règle 13 : Configurez l'entête ETags

Dans un premier temps, je vais m'intéresser à la règle 3, je suppose que vous avez déjà un serveur web Apache2 actif servant des fichiers (peu importe la technologie autour). La configuration suivante est utilisée sur ma Dedibox sous Ubuntu avec Apache2 mais doit pouvoir s'appliquer à peu près partout.

Ajoutez et configurez l'en-tête Expires

L'en-tête Expires indique quand un élément devra expirer du cache du navigateur; mettre une date d'expiration dans un futur lointain permet de maximiser l'utilisation du cache navigateur et donc d'éviter les téléchargements inutiles, ce qui est particulièrement utile pour les éléments statiques (images, feuilles de style, ...) qui ont tendances à changer ... peu fréquemment mais à ralentir l'affichage de la page si ils ne sont pas en cache. Pour ces éléments, il est possible de configurer l'expiration dans Apache avec le module expires . Pour les pages dynamiques ou éléments générés dynamiquement, c'est au script d'envoyer l'en-tête et sa valeur adéquate par exemple avec la fonction header() en PHP .

L'activation du module pour Apache2, il faut utiliser a2enmod avec la ligne suivante et ensuite recharger apache :

$ sudo a2enmod expires
$ sudo /etc/init.d/apache2 reload

Il reste alors à configurer ce module. Je stocke la configuration de ce module dans le fichier /etc/apache2/conf.d/expires dont voici le détail :

ExpiresActive On
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/x-icon "access plus 30 days"
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/x-javascript "access plus 30 days"

Tous les éléments statiques des types listés expirent 30 jours après leur premier téléchargement. Après un nouveau reload d'Apache, vous devriez voir apparaître l'en-tête Expires par exemple avec l'extension Firebug de Firefox au premier chargement des éléments de la page. Ensuite le navigateur utilisera son cache ce qui devrait accélérer l'affichage des pages suivantes utilisant les mêmes éléments.

Rappel des faits :
Une importante faille de sécurité a été mise en évidence le week-end dernier sur l’ensemble des noyaux Linux 2.6 récents (2.6.17 à 2.6.24.1). Elle permet à un utilisateur local d’obtenir les privilèges root. Il est fortement conseillé de mettre à jour votre noyau sur votre Dédibox.
Suivez le guide !


Téléchargez le nouveau kernel sur le ftp de dedibox sur ftp://ftp.dedibox.fr/pub/dedibox/kernel/r8-1/C7-X86-32bits/kernel-image-2.6.24.2-c7-r8-1.deb

Puis installez-le :
sudo dpkg -i kernel-image-2.6.24.2-c7-r8-1.deb

Relancez grub :
sudo update-grub

ATTENTION : NE REBOOTEZ SURTOUT PAS ! Sous peine de voir votre dedibox inutilisable !

Si toutefois vous aviez rebooté et que vous êtes bloqué (La dedibox ne redémarre pas), suivez les étapes du point 1 pour “réparer” votre Grub.
Sinon, passez directement au point 2.

1 - Connectez-vous à votre console dedibox : https://console.dedibox.fr
Passez votre dedibox en “mode rescue”
Récupérez votre mot de passe et votre adresse de connexion ssh
Attendez 1 bonne minute et connectez vous en ssh : mon_pseudo@ip_de_la_dedibox

Puis faites :
$ sudo -s
(+ mot de passe donné par console dedibox our le mode rescue)
# cd /mnt/
# mkdir mon_systeme
# mount -t auto /dev/sda2 mon_systeme/
# cd mon_systeme/
# chroot .
# mount -t auto /dev/sda1 /boot/
# cd /boot/grub/
# vim menu.lst

2/ Remplacez tous les root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx par root=/dev/sda2
Sauvegardez : avec Vim c’est :wq

… et maintenant vous pouvez rebooter !
#reboot

Vérifiez que vous êtes bien passé sur le nouveau kernel avec la commande :
uname -r

Vous devriez voir : 2.6.24.2dedibox-r8-1-c7

Plusieurs de mes sites tournent sur un serveur dédié Dedibox avec Ubuntu server. J’en suis parfaitement content depuis plus d’un an maintenant. (Ce n’est pas de la pub : c’est une évaluation ! :o) ) Bref : j’avais à l’origine installé la Dedibox en Ubuntu 6.06 LTS mais le passage à la 7.04 s’est mal passé. Réinstallation en 7.04 toute fraîche. J’ai entrepris ce matin de passer la Dedibox de 7.04 server vers 7.10 server…

Et, si la manipulation s’avère finalement assez simple, il est FORTEMENT recommandé de suivre la procédure qui va suivre pour éviter une grosse déconvenue : le non redémarrage pur et simple du serveur après l’upgrade.

j’ai tout simplement suivi la procédure indiqué sur HowtoForge (http://www.howtoforge.com/upgrade-ubuntu-7.04-server-to-7.10) et l’ai agrémentée d’une “astuce” trouvée sur les forums de dedibox-news.org.

Voici sommairement les étapes à suivre :

Je précise que je suis connecté à la Dedibox en SSH.

1 - sudo apt-get update 2 - sudo apt-get install update-manager-core 3 - sudo do-release-upgrade

Là, on va vous demander si vous souhaitez continuer en SSH et on vous prévient qu’il existe un “ssh de secours” sur le port 9004 … au cas où … je n’ai personnellement pas rencontrer le moindre problème !

Après la procédure est simple : vous répondez YES y à toutes les questions ou bien vous choisissez toujours les choix par défaut comme pour les question du style :

The default action is to keep your current version.

*** my.cnf (Y/I/N/O/D/Z) default=N ? <– ENTER or N

Pour Apache, j’ai choisi Apache2, apache et apache-ssl car j’ai une configuration un peu spéciale avec ISPConfig (apache + apache-ssl) et un serveur “normal” (apache2).

Services to restart for PAM library upgrade: <– saslauthd proftpd cron courier-authdaemon atd

What would you like to do about php.ini? <– keep your currently-installed version

Arrivé en fin de configuration, on me demande si je suis d’accord pour enlever 13 paquets qui “ne servent plus à rien” : je dis OUI

13 packages are going to be removed.

Continue yN Details d <– y

Puis arrive le moment fatidique du redémarrage ou vous voyez ces lignes :

System upgrade is complete.

At the end of the upgrade, a system restart is required:

Restart required

To fully ugprade, please restart

Continue yN <–

NE FAITES RIEN ICI !!! (… pour le moment !)

En effet si vous redémarrez “tel quel”, votre Dedibox ne REDEMARRERA PAS !!!

Explications :

Lors de l’upgrade votre /boot/grub/menu.lst n’a pas été touché ! Oui : car pour Dedibox, en gardant les dépôts installés par défaut, la dernière version du kernel est 2.6.21.1dedibox-r7. Vous devriez avoir un menu.lst avec deux lignes (au moins …) ou vous allez trouver ça :

root=UUID=45645653435444363533

… et c’est cette partie qui pose problème !

Il va falloir la changer comme suit :

## ## End Default Options ##

title Ubuntu 7.10, kernel 2.6.21.1dedibox-r7

root (hd0,0)

kernel /vmlinuz-2.6.21.1dedibox-r7 root=/dev/sda2 ro quiet splash

quiet

title Ubuntu 7.10, kernel 2.6.21.1dedibox-r7 (recovery mode)

root (hd0,0)

kernel /vmlinuz-2.6.21.1dedibox-r7 root=/dev/sda2 ro single

title Ubuntu 7.10, memtest86+

root (hd0,0)

kernel /memtest86+.bin

quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

Enregistrez.

Puis faites :

$ sudo update-grub

Et maintenant, vous pouvez redémarrer votre serveur. Tout devrait aller pour le mieux ! Cette configuration être propre à Dedibox car, sur un ordi personnel, je n’ai pas eu ce soucis …

Je continue tranquillement l'installation / la configuration de ma Dedibox sous Ubuntu hébergeant ce site . Après avoir fait cohabiter PHP4 et PHP5 , migrer son site utilisant eZ publish , configurer mes statistiques web avec AWStats et m'être battu avec PDO_MySQL (rien que ça :)), j'en viens aux backups. On ne le répètera jamais assez, il est important de faire des backups réguliers et systèmatiques comme il est important de savoir restaurer ses sauvegardes...

En plus, le service Dedibox propose un accès FTP avec un quota de 5Go inclu dans l'offre, il serait dommage de ne pas en profiter. Il est également possible d'augmenter ce quota, moyennant finances. Pour mon serveur, j'ai choisi d'utiliser cet espace pour sauvegarder les bases de données. C'est la partie la plus volumineuse et dans beaucoup de cas, c'est le seul élément à récupèrer. De toute manière, l'ensemble des données est aussi sauvegardé à intervalle régulier sur mon PC de bureau. Bien sûr les informations indiquées dans ce billet fonctionnent également avec n'importe quel autre accès FTP.

Configuration de MySQL

Il faut tout d'abord créer un utilisateur dans MySQL qui aura le droit en lecture sur toutes les bases pour faire un dump. Cela peut se faire via un assistant comme PHPMyAdmin ou bien avec 2 requêtes SQL exécutées en tant que root (de MySQL évidemment) :

GRANT SELECT, LOCK TABLES, SHOW DATABASES
  ON * TO 'backup'@'localhost' 
  IDENTIFIED BY 'pass_backup';
FLUSH PRIVILEGES;

L'utilisateur backup de MySQL a maintenant les droits en lecture sur toutes bases (il est conseillé de mettre un mot de passe fort...). Pour qu'un script puisse se connecter sans avoir à taper le mot de passe, il faut créer un fichier nommé .my.cnf dans le répertoire personnel de l'utilisateur qui exécutera le script. Ce fichier doit ressembler à :

[client]
 port      = 3306
 user      = backup
 password  = pass_backup 

Attention à bien restreindre les permission sur ce fichier pour que personne ne puisse le lire, sauf l'utilisateur en question avec la commande suivante :

> tigrou@dedipwet[88.191.30.29]:~$ chmod 600 .my.cnf

Configuration de l'accès FTP

Une fois l'option FTP activée dans la rubrique Sauvegarde de la console Dedibox, comme pour MySQL il faut faire en sorte que l'accès FTP se fasse sans demander de mot de passe. Il faut créer un fichier .netrc toujours à la racine du dossier personnel de l'utilisateur qui fera tourner le script :

machine dedibackup.dedibox.fr
login login_ftp_sauvegarde
password mot_de_passe_ftp_sauvegarde

Avec ce fichier, les connections FTP sur dedibackup.dedibox.fr se feront avec le login et le mot de passe indiqués avec les clients FTP suivant ce fichier (ftp , lftp , ncftp , ...) sans rien demander. De la même manière que le fichier .my.cnf, il faut faire attention aux permissions sur ce fichier.

Le script

#! /bin/bash
# Script de sauvegarde de toutes les bases sur FTP
 
FTP='dedibackup.dedibox.fr'
MYSQL_DIR='/var/lib/mysql'
TMP="/tmp/backup_site"
 
# fenêtre de backup en semaine
ROTATION_WEEK=3 
PREFIX_DATE=`date '+%U'`
PREFIX_DATE_DELETE=`date '+%U' -d "-${ROTATION_WEEK}weeks"`
 
[ ! -d "$MYSQL_DIR" ] && exit 2
[ ! -d "$TMP" ] && mkdir -p "$TMP"
 
cd "$MYSQL_DIR"
for base in `find . -maxdepth 1 -name [a-zA-Z]\* -type d` ; do
    base=`echo $base | sed 's#\./##g'`
    mysqldump --single-transaction "$base" | bzip2 -9 - > "$TMP/$PREFIX_DATE.$base.sql.bz2"
done
cd -
lftp -e "mrm $PREFIX_DATE_DELETE* ; mput $TMP/* ; exit"  "$FTP"
rm -rf "$TMP"

Ce script est prévu pour être lancé une fois par semaine avec crontab . Il va faire un dump de toutes les bases, effacer les dumps de plus $ROTATION_WEEK semaines sur le serveur distant et uploader les nouveaux ensuite. Le nombre de semaines sur lequel se fait la rotation peut être modifié via la variable ROTATION_WEEK.