Après avoir vu comment installer Drush, passons à un exemple pratique :

La mise à jour de votre site Drupal en ligne de commande grâce à Drush

Drupal is a registered trademark of Dries Buytaert

Drush peut vous faciliter la vie et vous faire gagner beaucoup de temps et automatisant des tâches répétitives.

Les mises à jour sont peu intéressantes et répétitives.

Utilisons Drush pour faire ces mises à jour

Pour rappel, Drush est un script utilisable en ligne de commande (terminal ou session SSH) et permettant d’exécuter des commandes sur votre site Drupal.

L’avantage de faire ces commandes dans un script, est que vous pouvez facilement enchainer ces commandes, càd automatiser la gestion de votre site ! Plus besoin de passer 20 minutes pour cliquer d’une page à l’autre de l’interface de gestion Drupal.

Je considère que vous avez un serveur de type LAMP, càd Linux Apache, MySQL et PHP, et que Drupal et Drush sont déjà installés.

Par défaut, Drush travaille sur le dossier actuel.

Mon site de test est http://test6.misson.net. Il est installé dans mon dossier /home/didier/www/test6

Je vais donc dans ce dossier et j’essaye quelques commandes :

« drush status »

$ cd /home/didier/www/test6/
:/home/didier/www/test6$ drush status
Drupal version : 6.14
Default theme : garland
Administration theme : garland
PHP configuration : /etc/php5/cli/php.ini
Drush version : 3.1
Drush configuration :
Drupal root : /home/didier/www/test6

Ce site n’est pas à jour… exactement ce qu’il faut pour faire notre test de mise à jour avec Drush

« drush statsmodules » ou « drush sm »

« drush sm » donne la liste des modules, s’ils sont activés ou pas, et leur version.

J’essaye depuis la « racine » de mon installation Drupal, mais ça ne fonctionne pas :

:/home/didier/www/test6$ drush sm
Could not find a Drupal settings.php file at ./sites/default/settings.php.   [error]
Command pm-list needs a higher bootstrap level to run
-you will need invoke drush from a more functional Drupal environment to run [error]
this command.
The drush command 'sm' could not be executed.

Dans mon cas, l’explication est simple.

Je n’ai pas de fichier de configuration par défaut ! Mon dossier « ./sites/default »  est vide.

Bien que mon installation ne comprenne qu’un seul site, j’ai pris l’habitude de travailler comme en multi-sites.

Mon fichier de configuration pour le site « test6.misson.net » se trouve dans ./sites/test6.misson.net.

J’ai 2 possibilités :

Soit je spécifie l’URL du site :

drush sm --uri=http://test6.misson.net

Soit je vais dans le dossier du site :

:/home/didier/www/test6$ cd sites/test6.misson.net/
:/home/didier/www/test6/sites/test6.misson.net$ drush sm
Package          Name                                              Type    Status
     Version
Administration   Administration menu (admin_menu)                  Module  Enabled
    6.x-1.5
CCK              Content (content)                                 Module  Enabled
    6.x-2.6
CCK              Content Copy (content_copy)                       Module  Enabled
    6.x-2.6
...
Core - optional  Color (color)                                     Module  Enabled
    6.14
Core - optional  Comment (comment)                                 Module  Enabled
    6.14
Core - optional  Contact (contact)                                 Module  Not
installed  6.14
...
Core - optional  Upload (upload)                                   Module  Enabled
    6.14
Core - required  Block (block)                                     Module  Enabled
    6.14
Core - required  Filter (filter)                                   Module  Enabled
    6.14
...
Image            Image Gallery (image_gallery)                     Module  Enabled
    6.x-1.0-beta3
Image            Image Import (image_import)                       Module  Enabled
    6.x-1.0-beta3
Image            ImageMagick Advanced Options (image_im_advanced)  Module  Enabled
    6.x-1.0-beta3
Other            Pathauto (pathauto)                               Module  Enabled
    6.x-2.x-dev
Other            Token (token)                                     Module  Enabled
    6.x-1.12
Other            Token actions (token_actions)                     Module  Not
installed  6.x-1.12
Other            TokenSTARTER (tokenSTARTER)                       Module  Not
installed  6.x-1.12
Other            Bluemarine (bluemarine)                           Theme   Disabled
     6.14
Other            Chameleon (chameleon)                             Theme   Disabled
     6.14
Other            Garland (garland)                                 Theme   Enabled
    6.14
Other            Marvin (marvin)                                   Theme   Disabled
     6.14
Other            Minnelli (minnelli)                               Theme   Disabled
     6.14
Other            Pushbutton (pushbutton)                           Theme   Disabled       6.14

Ce site Test6 n’est vraiment pas à jour, comme je l’avais d’ailleurs constaté via l’interface web :

En fait… j’ai quand même UN module à jour

Commençons les mises à jour :

Quand on travaille via l’interface Web habituelle, il est fortement recommandé de mettre votre site en mode maintenance, avant de commencer les mises à jour de modules ou de Drupal.

Étonnamment, il semble que ce ne soit pas nécessaire avec Drush !

Je vais malgré tout passer le site en mode maintenance…

Il n’y a pas de commande directement pour demander à Drush de passer le site en maintenance, mais il est possible de positionner une variable :

drush vset site_offline 1

Enter a number to choose which variable to set.
[0] : Cancel
[1] : site_offline (new variable)

pour éviter la confirmation (ce qui serait gênant dans un script), ajoutez « –always-set » :

$ drush vset --always-set site_offline 1
site_offline was set to 1.        [success]

Je vérifie dans l’interface Web du site. Ok, le site est bien en maintenance.

Pour rappel, il est TOUJOURS conseillé de faire un backup de vos fichiers ET de votre base de données avant de commencer un backup !

Je suppose donc que vous avez fait ce backup

Les mises à jour appliquent la dernière version du code Drupal ou des modules. Si vous avez vous même modifié ce code, vous devrez évidemment réappliquer vos modifications sur la nouvelle version des modules…

Vous pouvez mettre à jour un ou plusieurs modules précis.

Par exemple, pour ne mettre à jour que le module Token :

$ drush update token
Warning: The command name "update" is deprecated.
Please use a recommended form instead (pm-update,up).             [warning]
...

J’utilise donc la commande « pm-update » :

$ drush pm-update token
Refreshing update status information ...
Done.
Update information last refreshed: Sun, 07/04/2010 - 17:15

Update status information on all installed and enabled Drupal projects:
Name                            Installed version  Proposed version  Status
Administration menu             6.x-1.5            6.x-1.5           Up to date
Drupal                          6.14               6.17              SECURITY UPDATE available
Content Construction Kit (CCK)  6.x-2.6            6.x-2.7           SECURITY UPDATE available
FileField                       6.x-3.7            6.x-3.7           Up to date
Image                           6.x-1.0-beta3      6.x-1.0-beta5     Update available
ImageField                      6.x-3.2            6.x-3.7           SECURITY UPDATE available
Pathauto                        6.x-2.x-dev        6.x-2.x-dev       Update available
Token                           6.x-1.12           6.x-1.13          Update available
Code updates will be made to the following projects:
Token [token-6.x-1.13]
Note: Updated projects can potentially break your site. It is NOT recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue? (y/n): y

La mise à jour génère énormément de messages, qui défilent à toute vitesse, et beaucoup de messages d’erreur !

L’update (pm-update) fait :

• la mise à jour du module depuis le site Drupal.org (vous avez remarqué que je n’ai PAS téléchargé manuellement le module !)
• les mises à jours DB nécessaire (il fait le « update.php ») !
• le « clear cache« 

Les opérations de nettoyage donnent des messages d’erreur s’il n’y a rien à nettoyer.

C’est probablement normal (je n’ai pas eu le temps de tout lire).

Pas d’inquiétude donc !

Je vérifie dans l’interface Web :

Le module Token est bien à la dernière version disponible !

Si je lance la commande « drush pm-update » sans paramètre, elle s’appliquera à tous les modules… et au Core Drupal lui-même !

$ drush pm-update
Refreshing update status information ...
Done.
Update information last refreshed: Sun, 07/04/2010 - 17:36
Update status information on all installed and enabled Drupal projects:
Name                            Installed version  Proposed version  Status
Administration menu             6.x-1.5            6.x-1.5           Up to date
Drupal                          6.14               6.17              SECURITY UPDATE available
Content Construction Kit (CCK)  6.x-2.6            6.x-2.7           SECURITY UPDATE available
FileField                       6.x-3.7            6.x-3.7           Up to date
Image                           6.x-1.0-beta3      6.x-1.0-beta5     Update available
ImageField                      6.x-3.2            6.x-3.7           SECURITY UPDATE available
Pathauto                        6.x-2.x-dev        6.x-2.x-dev       Update available
Token                           6.x-1.13           6.x-1.13          Up to date
NOTE: A code update for the Drupal core is available.
Drupal core will be updated after all of the non-core modules are updated.
Code updates will be made to the following projects:

Content Construction Kit (CCK) [cck-6.x-2.7], Image [image-6.x-1.0-beta5],
ImageField [imagefield-6.x-3.7], Pathauto [pathauto-6.x-2.x-dev]

Note: Updated projects can potentially break your site.
It is NOT recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects,
you will have to migrate those modifications after updating.

Do you really want to continue? (y/n): Y

Je vérifie dans l’interface Web :

Tous les modules sont à jour, mais le core de Drupal ne l’est pas encore.

Je relance la commande :

$ drush pm-update
Refreshing update status information ...
Done.
Update information last refreshed: Sun, 07/04/2010 - 17:45
Update status information on all installed and enabled Drupal projects:
Name                            Installed version  Proposed version  Status
Administration menu             6.x-1.5            6.x-1.5           Up to date
Drupal                          6.14               6.17              SECURITY UPDATE available
Content Construction Kit (CCK)  6.x-2.7            6.x-2.7           Up to date
FileField                       6.x-3.7            6.x-3.7           Up to date
Image                           6.x-1.0-beta5      6.x-1.0-beta5     Up to date
ImageField                      6.x-3.7            6.x-3.7           Up to date
Pathauto                        6.x-2.x-dev        6.x-2.x-dev       Up to date
Token                           6.x-1.13           6.x-1.13          Up to date
Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files,
most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files,
please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site.
It is NOT recommended to update production sites without prior testing.
Do you really want to continue? (y/n): y
Project drupal was updated successfully. Installed version is now 6.17.
Backups were saved into the directory /home/didier/www/test6/backup/modules/20100704184539/drupal.                                                [ok]
Warning: MySQL server has gone away
query: INSERT INTO watchdog
(uid, type, message, variables, severity, link, location, referer, hostname, timestamp)
VALUES
(0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:105:\"MySQL server has gone away\nquery: SELECT name, schema_version FROM system WHERE type = 'module'\";s:5:\"%file\";s:43:\"/home/didier/www/test6/includes/install.inc\";s:5:\"%line\";i:81;}', 3, '', 'http://test6.misson.net/index.php', '', '127.0.0.1', 1278262302) in /home/didier/www/test6/includes/database.mysqli.inc on line 128
WD php: MySQL server has gone away                                                                                                                [error]
query: SELECT name, schema_version FROM system WHERE type = 'module' in /home/didier/www/test6/includes/install.inc on line 81.
MySQL server has gone away                                                                                                                        [error]
query: SELECT name, schema_version FROM system WHERE type = 'module' in /home/didier/www/test6/includes/install.inc on line 81.

An error occurred at function : drush_pm_post_pm_updatecode                                                                                       [error]
Backups were restored successfully.                                                                                                               [ok]
An error occurred at function : drush_pm_update

L’update du Core Drupal n’est PAS faite !

La version précédente  a été restaurée …

Je vérifie le site. Il semble tourner correctement, mais Drupal n’a effectivement pas été mis à jour.

Il semble que ce soit une question de ressource pour MySQL ! Mais que modifier ?

Je réessaye :

$ drush pm-update
Refreshing update status information ...
Done.
Update information last refreshed: Sun, 07/04/2010 - 19:23
Update status information on all installed and enabled Drupal projects:
Name                            Installed version  Proposed version  Status
Administration menu             6.x-1.5            6.x-1.5           Up to date
Drupal                          6.14               6.17              SECURITY UPDATE available
Content Construction Kit (CCK)  6.x-2.7            6.x-2.7           Up to date
FileField                       6.x-3.7            6.x-3.7           Up to date
Image                           6.x-1.0-beta5      6.x-1.0-beta5     Up to date
ImageField                      6.x-3.7            6.x-3.7           Up to date
Pathauto                        6.x-2.x-dev        6.x-2.x-dev       Up to date
Token                           6.x-1.13           6.x-1.13          Up to date

Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files,
most noteworthy among these are .htaccess and robots.txt.
If you have made any modifications to these files,
please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site.
It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y
Project drupal was updated successfully. Installed version is now 6.17.
Backups were saved into the directory /home/didier/www/test6/backup/modules/20100704202330/drupal.                                                [ok]
You have pending database updates. Please run `drush updatedb`
 or visit update.php in your browser.               [warning]
Executing system_update_6054                                                                                                                      [success]
CREATE TABLE {semaphore} (                                                                                                                        [success]
`name` VARCHAR(255) NOT NULL DEFAULT '',
`value` VARCHAR(255) NOT NULL DEFAULT '',
`expire` DOUBLE NOT NULL,
PRIMARY KEY (name),
INDEX expire (expire)
) /*!40100 DEFAULT CHARACTER SET UTF8 */
Executing system_update_6055                                                                                                                      [success]
ALTER TABLE {url_alias} DROP INDEX src_language                                                                                                   [success]
ALTER TABLE {url_alias} DROP KEY dst_language                                                                                                     [success]
ALTER TABLE {url_alias} ADD INDEX src_language_pid (src, language, pid)                                                                           [success]
ALTER TABLE {url_alias} ADD UNIQUE KEY dst_language_pid (dst, language, pid)                                                                      [success]
Executing imagefield_update_6006                                                                                                                  [success]
'all' cache was cleared                                                                                                                           [success]
Finished performing updates.                                                                                                                      [ok]
The following updates are pending:
system module
6054 - Add semaphore table.
6055 - Improve indexes on the {url_alias} table.
imagefield module
6006 - Add default values to all ImageFields.

Do you wish to run all pending updates? (y/n): y

Cette fois, toutes les mises à jour sont faites.

Même les « pending data base updates » (probablement suite au problème précédent) sont faites !

Si je relance la commande, tout est à jour.

L’interface Web me le confirme aussi !

Malgré tout, j’ai un risque, en tout cas sur mon serveur avec mes sites (vos sites sont peut-être plus légers, ou votre serveur configuré d’une autre façon…) d’avoir de nouveau cette erreur « WD php: MySQL server has gone away« .

Je réessayerai sur d’autres sites, en modifiant quelques options dans /etc/mysql/my.cnf

Cela pourrait venir du paramètre « max_allowed_packet = 32M« , à augmenter à 64M … mais je suis déjà à 64M !

Certaines personnes indiquent avoir résolu ce genre de problème (pas uniquement avec Drush) en augmentant à  »max_allowed_packet = 128M » ou même plus.

Si vous rencontrez ce problème, essayez donc (en sauvant votre fichier /etc/mysql/my.cnf avant) d’augmenter ce paramètre « max_allowed_packet », ou le paramètre « wait_timeout ».

Je referai des essais sur d’autres sites.

Mais, reste une opération à faire.

Le site est toujours en mode « Hors ligne » !

La commande pour remettre le site « en ligne » :

$ drush vset --always-set site_offline 0
site_offline was set to 0.

Voilà, le site est en ligne… et à jour !

Sources :

• module Drush (Drupal.org)
• Installer Drush pour administrer Drupal en ligne de commande (Drupalfr.org)
• Installer Drush pour administrer Drupal en ligne de commande par Julien Dubreuil
• Drush – Drupal Shell utility : liste des commandes disponibles
• Site maintenance mode (with Drush)
• DRUSH Update Question
• MySql :  » Warning: MySQL server has gone away  » – Tune MySql to resolve this problem

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil, Maxime Legrand et Sylvain Ratton.

Nouveau message d’Angie sur son blog www.webchick.net ce dimanche 10 janvier :

« As you may or may not have heard, on Friday we are going to roll Drupal 7.0 Alpha 1. This will be the very first time that the vastmajority of the community (not to mention the outside world) will download Drupal 7, and play around with all of the hard work you’ve all been doing for the past ~24 months. »

Angela Byron confirme donc Drupal version Alpha 1 pour ce vendredi 15 janvier.

Pour la première fois, une grande majorité de la communauté Drupal aura l’occasion de télécharger et jouer avec ce Drupal 7 alpha 1, fruit d’un dur travail de 24 mois.

Comme toutes les versions alpha et beta, c’est du TEST et donc il n’est préférable de ne PAS l’utiliser en production !

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil et Maxime Legrand.

OVH va lancer en janvier 3 offres de Cloud computing.

photo © OVH

Ce seront des offres de virtualisation souples en temps et en ressources

• miniCloud : 1.99Euro HT/mois
• coreCloud : 9.99Euro HT/mois
• myCloud : 49.99Euro HT/mois

Pas encore de détails sur ce Cloud computing à la sauce OVH, mais les béta devraient commencer dans les prochains jours. Il faudra donc attendre un peu pour la mise en production

Cette annonce ne m’étonne pas. Je l’attendais même…

Le Cloud Computing est en vogue actuellement. Cela permet bien plus de souplesse pour le client (le développeur Web) sans qu’il ne doive se préoccuper de serveurs Linx ou Windows, de prévision de charge, de serveurs qui saturent et où il faut en catastrophe commander ou louer de nouveaux serveurs car le site qu’on vient de lancer à un succès bien plus grand que prévu (ou bien moins grand… alors qu’on a prévu 10 énormes serveurs).

Typiquement, vous payez pour une service qui comprend l’hébergement de votre site Web sans vous occupez du matériel, ni des mises à jour Linux, etc. Si vous avez besoin de plus de puissance, vous rentrez dans votre interface de gestion chez votre founisseur (OVH dans ce cas) et en quelques clics vous validez l’utilisation de plus de ressources (cpu, bande passante, disque, mémoire) et votre site web en profite immédiatement sans rien devoir migrer ou réinstaller !

OVH avait déjà fait un pas dans cette direction avec les RPS : c’étaient des serveurs réduits à une carte mère, sans disque dur physique. Le stokage se faisait en SAN (des disques reliés en iSCSI). Vous aviez alors la possibilité de basculer en quelques minutes d’un serveur avec une carte mère Atom simple core, vers un Atom Dual Core ou AMD X2 ou Phenom Quad, sans rien devoir réinstaller, et sans devoir même recopier vos bases de données et vos fichiers ! Le principe était simple : vos partitions de disques iSCSI étaient simplement détachées logiquement de votre ancien serveur pour être rattachées à votre nouvelle carte mère plus puissante !

De la même façon, vous pouviez demander une augmentation disque sans devoir attendre l’installation physique d’un nouveau ou second disque dur dans votre serveur.

Le Cloud offre tout cela de façon bien plus souple !

Vous n’avez même plus à vous poser la question du type de cpu que vous voulez, ni sur quel serveur vous êtes : vous demanderez simplement à OVH « je veux plus, plus de ram, plus de puissance cpu, plus de bande passante » … et tout ira tout seul !

euh… presque… Faudra quand même sortir sa carte de crédit si vous voulez plus

Le Cloud Computing, c’est un peu les avantages des serveurs dédiés (plus puissant que de l’hébergement, plus souple, mieux isolés des autres) sans se préoccuper des problèmes de gestion d’un dédié (comme en mutualisé) et sans la limite physique d’un serveur dédié (passer d’un serveur à un autre plus gros, évoluer d’un à deux ou plusieurs serveurs).

Source : Octave (mailing list OVH samedi 9 janvier 2009 13h47)

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil et Maxime Legrand.

Que faire quand votre serveur crash, pour diverse raison (bug, power off, problème hardware) et qu’au redémarrage MSQL vous donne un message ?

WARNING: mysqlcheck has found corrupt tables

Le plus prudent est d’avoir un backup très récent !

Mais que faire si vous n’en avez pas de récent, ou même pas de backup du tout ?

Je me base les documentations suivantes :

• l’article Réparation Mysql en masse de Un blog qui nous veut du bien
• CHECK TABLE Syntax du site MySQL
• REPAIR TABLE Syntax du site MySQL

Le serveur tourne sous Debian, mais les commandes sont valables pour pratiquement tout distribution Linux ou autres (BSD, etc) et pour toute version récente de MySQL.

MySQL a le moyen de réparer (ou du moins d’essayer) les tables corrompues.

En général, cela fonction dans la majorité des cas… mais pas tous… ce qui justifie bien la nécessité d’un BACKUP régulier !

Il y a au moins 2 moyens de procéder.

• utiliser mysqlcheck pour tout réparer en bloc, mais cela nécessite un arrêt du service MySQL, ce qui perturbera les autres applications ou sites Web se trouvant sur votre serveur
• utiliser une commande « repair table » dans MySQL. Cela ne nécessite pas l’arrêt de MySQL et c’est relativement simple… si vous n’avez pas des dizaines de tables corrompues

Je vais utiliser la 2ème méthode : réparer table par table.

Connectez vous à MySQL.
Le user « root » est le userid root de MySQL. Ce n’est pas nécessairement « root ». Il peut être différent de votre « root » Linux !

$ mysql  -u user_root_mysql  -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6258
Server version: 5.0.32-Debian_7etch11-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Vous êtes dans MySQL. Il attend vos commandes.

Il faut d’abord préciser sur quelle base de données vous voulez travailler, et ensuite les commandes pour contrôler et réparer  la ou les tables corrompues.

Ma base de données s’appelle ‘ »mabase » et les tables à l’intérieur de cette base s’appellent « culbutte_accesslog » et « culbutte_cache_menu ».

Utilisez évidemment les noms de votre DB et de vos tables corrompues

mysql> USE mabase;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql>

Vérification des tables :

mysql> CHECK TABLE culbutte_accesslog;
+-----------------------------+-------+----------+----------+
| Table                       | Op    | Msg_type | Msg_text |
+-----------------------------+-------+----------+----------+
| culbutte.culbutte_accesslog | check | status   | OK       |
+-----------------------------+-------+----------+----------+
1 row in set (0.13 sec)

La première table, bien que n’ayant pas été fermée correctement, n’est pas corrompue

mysql> CHECK TABLE culbutte_cache_menu;
+------------------------------+-------+----------+------------------------------------------------------------------------------------+
| Table                        | Op    | Msg_type | Msg_text                                                                           |
+------------------------------+-------+----------+------------------------------------------------------------------------------------+
| culbutte.culbutte_cache_menu | check | error    | Table './culbutte/culbutte_cache_menu' is marked as crashed and should be repaired |
+------------------------------+-------+----------+------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Malheureusement, cette table est corrompue et doit être réparée !

Réparons la. La commande est très simple :

mysql> REPAIR TABLE culbutte_cache_menu;
+------------------------------+--------+----------+------------------------------------------------+
| Table                        | Op     | Msg_type | Msg_text                                       |
+------------------------------+--------+----------+------------------------------------------------+
| culbutte.culbutte_cache_menu | repair | info     | Wrong bytesec:   0-  0-  0 at 4335740; Skipped |
| culbutte.culbutte_cache_menu | repair | status   | OK                                             |
+------------------------------+--------+----------+------------------------------------------------+
2 rows in set (0.11 sec)

Vérifions une dernière fois :

mysql> CHECK TABLE culbutte_cache_menu;
+------------------------------+-------+----------+----------+
| Table                        | Op    | Msg_type | Msg_text |
+------------------------------+-------+----------+----------+
| culbutte.culbutte_cache_menu | check | status   | OK       |
+------------------------------+-------+----------+----------+
1 row in set (0.01 sec)

Allons sur le site (en Drupal, mais ça aurait pu arriver sur n’importe quel site ou application puisque le problème est un reboot du serveur).

Le message d’erreur n’avait pas disparu. J’ai du vider le cache (Flush all cache via le Admin-menu de Drupal) pour regénérer la page.
A ce moment là, le message d’erreur a disparu et le site tourne correctement

Ouf …

Voici les premières photos sur Flickr : Drupalcampbe 20091211

Je serai au DrupalCamp, à Gand, ces vendredi 11 et samedi 12 décembre.

Ce DrupalCamp est le 2ème organisé en Belgique, cette fois par la communauté néerlandophone.

La majorité des présentations et conférences devraient être en anglais. En général, 2 ou 3 conférences ou ateliers ont lieu en même temps, vous permettant de choisir en fonction de vos intérêts ou de votre niveau de connaissance…

Malgré tout, parfois le plus dur est de choisir UNE conférence

J’avais déjà assisté au DrupalCamp de Louvain-la-Neuve, organisé par notre ami Gilles Bailleux de Drupalfr.be, en juin dernier.

Pas la peine (malheureusement) de vous y précipitez car les places disponibles sont parties très rapidement, mais j’essayerai de vous tenir au courant en publiant plusieurs billets sur mon blog et sur WebActus… si le WiFi sur place tient la charge des nombreux visiteurs et de leurs laptops et smartphones WiFi

Malgré que Linux soit d’un relativement haut niveau de sécurité, il est toujours bon de faire régulièrement quelques vérifications.

ChkRootKit fait exactement ce que son nom dit : Il parcourt votre disque dur à la recherche de rootkit.

Je viens de corriger et mettre à jour mon article écrit il y a presque exactement 2 ans. Cet article est toujours d’actualité, que l’on soit en Debian ou Ubuntu, en 8.04 LTS ou en 9.10…

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil et Maxime Legrand.

Déjà 10 ans…

photo © OVH

Octave l’a annoncé ce lundi 2 novembre (mais j’étais en déplacement pour le Micromania Game Show 2009).

Il insiste sur le fait qu’OVH, c’est avant tout une équipe, et que même si cette équipe fait maintenant plus de 200 personnes en France, l’esprit d’équipe et la confiance sont toujours les éléments clés de ce succès !

« OVH, une équipe qui rame ensemble, dans la même direction »

(oui oui, c’est mieux dans la même direction )

Bon anniversaire OVH

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil.

Octave vient de l’annoncer ce samedi à 1h04 sur la mailing list « Hosting » d’ OVH :

« Une bonne nouvelle: la distribution Ubuntu 9.10 « Karmix Koala » vient d’être annoncée et elle est déjà disponible chez OVH en version serveur (32 ou 64bit) !
Comme une bonne nouvelle n’arrive jamais seule, on vous propose de l’installer en Ext4 via le manager ! »

Ah, ça c’est cool… et vachement rapide !
Moins de 36h après la sortie officielle d’Ubuntu 9.10 ! Super !
Chez certains hébergeurs, on attend parfois des semaines avant de voir apparaitre les nouvelles distributions… Ce n’est pas le cas d’ OVH.

photo © OVH

Merci Octave !

… enfin… « merci Octave »… J’ose espérer que tu n’es pas le seul à faire tout ce boulot !
OVH c’est toute une équipe… et elle semble très bien fonctionner

Ubuntu server chez OVH

Article publié également sur WebActus.

Là, je suis impressionné !

Je ne sais pas si je verrai un jour un engin d’une telle puissance en réalité (il vaut peut-être mieux pas…), mais je suis impressionné ! (je sais, je l’ai déjà dit…).

photo Char AMX Leclerc, Wikipedia, licence Creative Commons by-sa 2.0

Que vient faire un Tank Leclerc dans ce blog ?

RIEN…  enfin si… quand même…

Et ça n’a évidemment rien à voir avec l’industrie de l’armement !

Tank Leclerc 144T ? … une idée … d’OVH !

Ils ont de l’humour aussi chez OVH (pas que Google avec ses pâtisseries !)

Un tank n’est pas qu’un char d’assaut ! C’est aussi un réservoir en Inde. Ce mot est passé en anglais pour désigner un réservoir…

Un réservoir, vous commencez à avoir une idée ?

Oui ! Du storage évidemment ! C’est un gros réservoir de stockage Data, c’est à dire : des disques durs !

Et le modèle 144T … ce ne serait pas 144 Tera bytes ?

Oui ! Voilà ! On y est

OVH vient de renouveler sa gamme de serveur HG, leur haut de gamme.

Un de ces serveurs peut contenir 8 disques de 1 Tera, plus 12 disques dans un boîtier d’extension. Cela fait 20 Tera… extensible à maximum 144 Tera bytes !

Tank Leclerc © OVH

C’est Octave qui l’a dit… je le crois

Le serveur HG 2010-10G Extra Large, 8 TeraBytes + Extension 12 TeraBytes (total 20 TeraBytes), avec interface réseau TenGiga (oui, oui, du 10Gbps) est dans leur liste de prix. L’extension à 144 Tera, je ne l’ai pas encore vue… Faut certainement attendre un peu.

Là, je suis impressionné !

Article publié également sur WebActus.