Installation de Debian (Squeeze) sur un IBM X3550M4 avec carte RAID M5110 [basé sur LSI SAS2208 ROC] (firmware mars 2012)

Petite introduction utile sur le choix d’une carte RAID matérielle pour un serveur qui se doit d’être performant côté accès disques :

- prendre une carte RAID avec du cache (typiquement chez IBM la M5110 a 512 Mo de Cache tout comme chez Dell la Perc H700 NV)

- qui dit cache, dit nécessité d’avoir aussi une batterie sur cette carte RAID pour pallier à une coupure électrique soudaine.

La carte LSI M5110 (proposée sur les IBM X3550 M4 notamment) est une carte RAID de bonne qualité aux caractéristiques suivantes :
8 ports internes 6 Gbps SAS/SATA
2 x4 mini-SAS connecteurs internes (SFF-8087)
Supporte RAID niveaux 0, 1, et 10
Supporte RAID 5 et 50 avec option M5100 Series RAID 5 mise à jour
Supporte RAID 6 et 60 avec option M5100  Series RAID 6 mise à jour
Supporte batterie 512 MB battery-backed cache ou 512 MB / 1 TB flash-backed cache

Par défaut avec les iso officielles Debian Squeeze la version du driver megaraid_sas ne sera pas assez récente pour détecter le volume que vous aurez créé via les outils IBM sur cette carte RAID.

Il faut le module noyau présent actuellement uniquement dans le dépôt Sid.
Plusieurs possibilités :
- Récupérer le driver et installer via USB lors de l’installation comme avec la carte controleur LSI Logic MegaRAID SAS 9240-8i

- Utiliser un dépot avec des iso modifiées pour supporter ce type de matériel récent. Dans notre cas précis celui de Kenshi Muto convient.
Ainsi l’iso Netboot pour un IBM X3550M4 avec carte RAID M5110 (cache de 512 Mo) est :  Netboot [from squeeze-custom-amd64-0315.iso - kernel version 3.2.4, Debian 6.0.4 with firmwares]

Bonne installation !

Surveillance de vos sites web

Toujours à la recherche d’évolutions pour améliorer notre service d’infogérance, nous proposons désormais à tous nos clients un service de surveillance de sites web. L’idée est de mesurer le temps de réponse de certaines pages web du point de vue d’un visiteur, donc directement derrière une connexion ADSL. Nous nous concentrons pour l’instant sur les visiteurs français ; nous avons donc pris des connexions standards et répandues : une Livebox (Orange), une 9box (SFR) et une Freebox (Free), derrière lesquelles nous avons mis en place des mini-machines (Sheevaplug), ce qui nous permet de mesurer le temps de réponse d’une machine (PING), d’un site web (HTTP) ou même d’une résolution de nom de domaine (DNS). Des courbes sont tracées avec possibilité de zoom et conservation sur 400 jours.

En cas de temps de réponse trop important ou d’une coupure, des alertes sont générées et envoyées par mail sur les adresses de votre choix. On peut par exemple définir une alerte si une page répond trois de suite en plus de 500ms. Définir des alertes personnalisées est très simple ! De plus, grâce aux différents points de surveillance (Orange, SFR, Free, datacenter Evolix), les informations peuvent être recoupées, permettant de s’assurer de la bonne disponibilité d’un site en englobant tous les aspects (problème box du FAI, routage/latence chez le FAI, routage/latence de l’hébergement, disponibilité et état du serveur, bon fonctionnement du service HTTP, bon fonctionnement de l’appilcatif, etc.). Fini (ou presque) les tests depuis un navigateur pour savoir si votre site répond ou si il n’est pas lent !

Évidemment, on s’appuye sur des logiciels libres pour ce service, et principalement le logiciel Smokeping qui gère tout cela. Vous pouvez donc nous demander la mise en place d’alertes spécifiques (précisez nous la page, la règle de détection et les adresses mail pour recevoir les alertes). Ceci est inclus dans notre infogérance serveur… une raison de plus pour y souscrire pour vos serveurs critiques !

Les courbes statistiques sont bien sûr privées pour chaque client, mais néanmoins nous mettons publiquement certaines courbes (vers Google.fr, Evolix.fr, ns4.evolix.net, Orange.fr, Free.fr, Sfr.fr) qui peuvent être utiles à tout moment pour voir si un problème impacte un opérateur particulier ou notre hébergement : http://public.smokeping.evolix.org/

Sortie du Debian Handbook sous licence libre

Vous connaissez peut-être le Cahier de l’Admin Debian (éditions Eyrolles), un MUST-HAVE notamment pour tout sysadmin voulant maîtriser l’infogérance de serveurs dédiés, que nous offrons d’ailleurs lors de nos formations Evolix. Voici maintenant le Debian Handbook en anglais et surtout sous licence libre ! Projet lancé il y a moins d’un an sous forme d’un appel à des contributions financières, le pari a été gagné par les auteurs Raphaël Hertzog et Roland Mas. Vous pouvez donc le lire en HTML, en PDF, le télécharger via P2P, l’acheter, l’offrir, le donner, le copier, le modifier, le revendre et même l’installer via apt-get !

Note : Nous avons modestement supporté financièrement la sortie du Debian Handbook, ce qui nous vaut des remerciements en préface !

Mettre un site en maintenance en urgence

Dans le métier de l’infogérance serveur, il arrive de devoir gérer un incident en urgence qui rende indisponible un site Internet. Pendant cet incident, surtout si il est matériel ou réseau, les visiteurs sont alors confrontés à des erreurs peu esthétiques (« Unable to connect », « Timeout », erreurs 5xx, etc.) sans compter les Google bot qui peuvent passer juste à ce moment là. Bien sûr, nous préconisons la mise en d’un PRA voire d’un PCA mais lorsque ce n’est pas fait, il est pratique d’avoir une solution toute prête… car il y a souvent l’incident lui-même à gérer. Notre technique : baisser le TTL du nom de domaine et rediriger les enregistrements DNS vers l’IP 178.32.99.219 ; cela a pour effet de renvoyer avec une redirection HTTP 302 n’importe quelle page du site concerné vers une page de maintenance simple tout en conservant le domaine : http://178.32.99.219/

PHP 5.3, back to PHP 5.2

Comme vu dans l’article PHP 5.2 goto PHP 5.3, le passage de PHP 5.2 à PHP 5.3 lors d’un upgrade de Lenny à Squeeze peut poser des problèmes de compatibilité.

Il est possible de downgrader PHP 5.3 et de repasser (temporairement) à PHP 5.2 sur Squeeze en utilisant directement les paquets Lenny:

  •  rajouter dans /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ lenny main contrib non-free

  • modifier le fichier /etc/apt/preferences (ou /etc/apt/preferences.d/fichier) :

Package: libapache2-mod-php5 php5 php5-common php5-cli php5-mysql (…)
Pin: release a=oldstable
Pin-Priority: 1001

  • désinstaller les packages PHP 5.3 :

aptitude update
aptitude remove `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`

  • installer les packages PHP 5.2 en spécifiant la target lenny (oldstable) :

aptitude install -t oldstable `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`

On vérifie que les versions sont correctes et on peut redémarrer Apache.

La commande date

Commande plutôt simple et de base sur un système Unix, date a pas mal de petites options sympa.
Un petit exemple quand on construit une politique de sauvegarde sur un serveur Linux (réflexe de base à avoir quand on administre un serveur) avec par exemple l’idée de garder une archive par mois sur les deux derniers mois du répertoire de sauvegarde (nommé save).
L’idée étant en crontab par exemple d’avoir des commandes du style :

cp -al /home/save/ /home/archive/save`/bin/date +\%Y\%m\%d`
rm -rf /home/archive/save`/bin/date --date='2 months ago' +\%Y\%m\%d`

On note le date --date='2 months ago' bien pratique !

PHP 5.2 goto PHP 5.3

Passage de Debian Lenny à Debian Squeeze oblige pour tout serveur correctement infogéré, beaucoup de développeurs sont en train de valider leurs codes pour passer de PHP 5.2 à PHP 5.3.
Si vous rencontrez dans vos journaux d’erreur quelque chose comme :

PHP Parse error: syntax error, unexpected T_GOTO, expecting T_STRING or ‘(‘ in /arborescence/fichier.php on line 43

C’est que votre code PHP a été écrit avec une fonction prénommée goto ….
Or goto est un mot réservé en PHP >= 5.3.0 (car nouvelle méthode)
À vos grep/sed :)

crossdomain.xml pour du crossdomain en Flash

Le principe d’une animation Flash est de s’exécuter sur le navigateur du client et non pas sur votre serveur web (qui a une infogérance Evolix bien sûr ;-) ). Des restrictions sont donc en place sur les players Flash récents lorsque l’animation tente de charger des éléments extérieurs : par défaut, cela n’autorise que le chargement des images. En effet, une animation Flash malicieuse pourrait charger des éléments secrets sans ces restrictions de sécurité (par exemple, révéler le contenu d’un intranet sur un réseau interne d’entreprise) ! Néanmoins, on peut autoriser des éléments à être chargés par une animation Flash en créant un fichier crossdomain.xml du type :

<?xml version="1.0"?>
<cross-domain-policy>
        <allow-access-from domain="*"/>
</cross-domain-policy>

…que l’on placera à la racine du serveur avec les éléments à charger (et non pas sur le serveur web servant l’animation).

Prenons un exemple d’un site http://www.example.com/ contenant une animation foo.swf qui charge un fichier http://static.example.com/flux.rss : il faudra donc positionner un fichier http://static.example.com/crossdomain.xml

Pour plus de détails, voir sur http://kb2.adobe.com/cps/142/tn_14213.html

Ajouter un disque dans un volume RAID5 hardware

Prenons un serveur DELL avec un controlleur RAID et un volume RAID5 configuré. Vous l’utilisez (sous Linux bien sûr) et un jour vous avez besoin d’ajouter un disque pour avoir plus de place. Est-ce possible ?

Ça dépend du controlleur RAID !

La capacité d’étendre un volume RAID5 en recalculant l’ensemble du volume (la parité étant répartie sur tous les disques) dépend d’un controlleur RAID à un autre. Difficile de donner des proportions, mais forcément plus un controlleur sera cher plus il aura de chance de le supporter. Revenons à notre exemple d’un serveur DELL, équipé d’une classique carte RAID PERC 5/i. Après avoir rajouté un disque, si l’on va dans le BIOS de la carte RAID : aucune trace de la possibilité d’étendre un volume ! On peut le supprimer, modifier ses options, mais absolument pas rajouter un nouveau disque. En fait, cette fonctionnalité n’est pas accessible depuis le BIOS… mais elle est possible via un outil en ligne de commande ! Voici une ligne de commande permettant d’ajouter un disque dans un volume RAID5 existant :

# omconfig storage vdisk action=reconfigure controller=0 vdisk=0 raid=r5 \
 pdisk=0:0:0,0:0:1,0:0:2,0:0:3,1:0:5
Command successful!

Et au niveau système, ça se passe comment ?

Une fois cette commande lancée, on peut constater dans le BIOS que le volume RAID5 est en cours de reconstruction. On le voit aussi au niveau système (avec l’outil MegaCli) :

Reconstruction           : Completed 17%, Taken 99 min.

Cela va durer plusieurs heures où les accès au volume RAID sera très lent…

Tant que ce n’est pas terminé, le système verra toujours le volume avec son « ancienne » taille :

sd 0:2:0:0: [sda] 1754529792 512-byte logical blocks: (898 GB/836 GiB)

Une fois terminé, le système verra après un reboot la nouvelle taille :

sd 4:2:0:0: [sda] 2339373056 512-byte logical blocks: (1.19 TB/1.08 TiB)

On verra donc sans rien faire de plus la nouvelle taille via les outils fdisk/cfdisk/etc. et donc un espace supplémentaire en Free Space.

Il reste ensuite à gérer cela au niveau partitions et filesystem. Voici un exemple où l’on rajoute une partition LVM et l’on étend d’un LV existant :

# cfdisk /dev/sda
# partprobe
# pvcreate /dev/sda10
  Physical volume "/dev/sda10" successfully created
# vgextend group1 /dev/sda10 
  Volume group "group1" successfully extended
# lvextend -L+250G /dev/mygroup/srv
  Extending logical volume srv to 550.00 GiB
  Logical volume srv successfully resized
# umount /srv
# resize2fs -p /dev/mygroup/srv
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/mygroup/srv' first.
# e2fsck -f /dev/mygroup/srv
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mygroup/srv: 16/19660800 files (0.0% non-contiguous), 46720716/78643200 blocks
# resize2fs -p /dev/mygroup/srv
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mygroup/srv to 144179200 (4k) blocks.
Begin pass 1 (max = 2000)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/group1/srv is now 144179200 blocks long.
# mount /srv
# df -h /srv
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/group1-srv
                      542G  174G  341G  34% /srv

Et voilà, c’est donc possible dans certains cas.

mysql -o

Si vous avez une sauvegarde de base de données MySQL réalisée avec la commande mysqldump –all-databases il est souvent fastidieux de découper le fichier pour récupérer une base de données particulière. Une option de la commande mysql est faite pour cela : mysql -o

Vous pouvez donc restaurer une base de données ainsi :

mysql> create database foo
$ mysql -o foo < all-databases.sql

Note : la base de données foo doit déjà exister.

WordPress Themes