GNU Squad

J’ai créé, il y a quelques temps, un petit script répondant au doux nom de « bonne_bouffe.sh » (m’avertissant par mail lorsqu’il y a de la pizza succulente à la brasserie du coin ) que je voulais exécuter une fois par semaine ; j’ai donc créé une tâche planifiée (un « cron job ») en créant un lien symbolique vers mon script dans le répertoire « /etc/cron.weekly », jusque là tout va bien sauf qu’au bout de quelques semaines je n’avais toujours rien reçu !

Aujourd’hui, je décide donc d’aller jeter un œil dans les logs sans y trouver de traces d’exécution de mon script alors que ses petits copains dans le répertoire étaient eux, bien exécutés !

Que diable se passe t-il ? Pour le savoir, il faut chercher la manière dont sont lancées ces tâches planifiées. Un petit tour dans le fichier « /etc/crontab » nous montre ceci :

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Nous voyons donc que les tâches sont exécutées grâce à la commande « run-parts ». Intéressons-nous au manuel de cette commande : « man run-parts ».

run-parts exécute tous les fichiers exécutables situés dans répertoire, et dont le nom satisfait les contraintes décrites ci-dessous. Les autres fichiers sont ignorés.

Si ni l’option –lsbsysinit ni l’option –regex n’est pas utilisée, alors les noms ne doivent être constitués que de lettres minuscules ou majuscules, de chiffres, de tirets de soulignement (« underscore ») ou de tirets.

Le problème apparaît alors clairement : notre lien symbolique, reprenant le nom du script, contient un point et n’est donc pas exécuté !

Deux solutions s’offrent alors à nous pour résoudre ce problème :

• ajouter l’option « –lsbsysinit » à « run-parts » pour les 4 lignes présentes dans « /etc/crontab »
• renommer le lien symbolique « bonne_bouffe.sh » en « bonne_bouffe »

Personnellement, j’ai choisi la seconde solution afin de coller à la façon de faire de Debian

Dans un précédent billet, nous apprenions qu’il y allait avoir du changement au niveau de la distribution de MySQL sans savoir si cela allait être en faveur ou en défaveur du libre.
MySQL, sous la pression de Sun, a tranché et Kaj Arnö, vice président en charge de la communauté open source, nous informe que MySQL Server est, et restera complètement fonctionnel et open source ainsi que ses différents connecteurs et moteurs de tables. À cela s’ajoute quelques nouveautés très intéressantes axées sur les sauvegardes qui seront également placées en open source :

• les fonctionnalités de pending backup
• le driver MyISAM natif permettant de mixer des backups logiques et physiques
• les fonctionnalités de chiffrement et de compression lors des backups

Nous voilà donc rassurés !

Sources :

• MySQL : un peu moins ou un peu plus libre ?
• MySQL Server is open source even backup extensions
• Présentation : MySQL Online Backup (téléchargement local)

Et la marmotte vous allez me dire ? La marmotte en l’occurrence c’est Microsoft qui nous offre deux screencats censés démontrer la facilité de Windows et le gain de temps procuré comparé à une solution GNU/Linux. Si l’on s’en tient à ça, pourquoi pas, c’est même intéressant mais quand il y a parti pris, c’est plutôt risible qu’autre chose.

Pour leur « démonstration », les ingénieurs de Microsoft ont utilisés ce qui semble être un Windows 2003 Server 64 bits ainsi que la version 7.04 d’Ubuntu en 64 bits également.

Commencons par détailler le screencast Windows : celui-ci démarre par l’installation de Perl en mode CGI accompagné d’un script de test, pour cela, ils ont eu besoin d’un double clic, de 32 clics et de 4 commandes à taper puis ils sont passés à l’installation de PHP, toujours en mode CGI, accompagné lui aussi de son script de test et qui a nécessité quant à lui, 5 double-clics et 18 clics ce qui fait au total : 6 double-clics, 50 clics et 4 commandes à taper !!!

Passons maintenant au screencast Ubuntu : les ingénieurs de Microsoft ont commencés par installer PHP en tant que module Apache ce qui a nécessité : 1 double-clic et 2 commandes à taper puis ils ont réitérés la chose avec Perl, toujours en tant que module, l’installation a nécessité 1 double-clic et 5 commandes à taper ce qui donne au total 2 double-clics et 7 commandes à taper.

Rapidement, en tant que Linuxien convaincu, on pourrait dire qu’ils se sont bien plantés dans leur « démonstration » vu la facilité avec laquelle Perl & PHP ont été installés sous Ubuntu comparé au cliquodrôme Windows qui nous fait perdre plus de temps qu’autre chose ! D’ailleurs, si l’on s’en tient aux chiffres, le screencast Windows est 20 secondes plus long que son concurrent !

Cependant, leur but était de faire peur aux aficionados de Windows en leur montrant de la ligne de commande, chose qu’ils n’ont pas l’habitude de pratiquer et qui par conséquent, fait peur. Le fair-play aurait été de mise, ils auraient, sous Ubuntu, installer Perl & PHP avec Synaptic et copié les fichiers avec Nautilus mais ça aurait été trop simple.

On peut remarquer également que sous Windows, les programmes d’installation étaient déjà téléchargés sur le bureau alors que sous Ubuntu, tout est téléchargé durant le screencast sur les serveurs de la distribution ; imaginez maintenant le temps qu’il aurait fallu pour télécharger les deux programmes d’installation sous Windows : lancer le navigateur, surfer sur les sites de PHP & Perl, trouver l’espace de téléchargement, télécharger les versions correspondant au système d’exploitation, mine de rien ça aurait pu doubler le temps de leur screencast ! Tout ceci sans compter le fait que pour les futures mises à jour de ces logiciels, il aurait fallu tout rechercher sur internet et tout réinstaller laborieusement alors que sous Ubuntu, les mises à jour se seraient faites quasi automatiquement !

Autre différence : en tant que Windowsiens pur & dur, ils tournent sous le compte administrateur alors que sous Ubuntu, bien évidemment, c’est un compte utilisateur avec lequel il faut utiliser « sudo » pour exécuter des commandes privilégiées : c’est tout bon pour Microsoft car ça rallonge les lignes de commandes et on peut facilement faire semblant de l’oublier pour provoquer une erreur comme ils l’ont fait lors du changement de droits sur l’exemple Perl avec « chmod ».

Ils sont bien rigolos aussi au niveau de l’édition des fichiers : une fois ils utilisent Gedit, une autre fois ils utilisent pico en ligne de commande qui, il faut l’avouer, est plutôt moche à voir. Rien de tel pour embrouiller un Windowsien !

Une dernière chose : sous Windows, ils installent les applications en mode CGI alors que sous Ubuntu, celles-ci sont installées en tant que module ce qui est grandement avantageux niveau performances ; pourquoi n’ont-ils pas installés Perl & PHP en mode ISAPI (équivalent des modules d’Apache) sous Windows ? Tout simplement parce que ça aurait complexifié l’installation et rallongé leur screencast, ce qui n’était pas leur but !

Bref, tout ceci n’est qu’une bonne blague de la part de Microsoft, j’attend les screencasts suivants avec impatience, pas vous ?

Sources :

• Get the facts
• Screencast Perl & PHP sous Windows (téléchargement local)
• Screencast Perl & PHP sous Ubuntu (téléchargement local)

Triste nouvelle qui est tombée hier : les éditions françaises d’O’Reilly, qui nous publiaient d’excellents ouvrages informatiques en français, viennent de fermer définitivement suite à un trop faible volume de ventes.

Sources :

• O’Reilly France
• Blog Immatériel : O’Reilly France, c’est déjà du passé