Voulant installer Qt4 et QtCreator sur ma fedora 16 toute fraiche, je me suis heurté, lors de la première tentative de compilation, à une erreur pour le moins étonnante (lorsque j’ai fait « run qmake ») :

/usr/share/qt4/mkspecs/linux-g++/qmake.conf.

Après avoir fait une rapide recherche infructueuse sur le net, j’ai fait une petite recherche sur mon disque dur sur le terme « mkspecs » et je trouve qu’il se trouve en fait dans /usr/lib64/qt4/mkspecs.
Dans une tentative un peu naïve, je tente le lien symbolique, me disant que ça doit encore être une histoire de 64bits pas super bien géré :

sudo ln -s /usr/lib64/qt4/mkspecs /usr/share/qt4/mkspecs

Eh bien… ça marche !! Problème semble résolu, on dirait bien que ça compile même !
Avis aux amateurs qui auront le même souci, donc… Et si ça ne résoud pas le souci mais que vous avez une autre solution, ou que vous voulez apporter une quelconque info supplémentaire, ajoutez un commentaire !!

——————————- English Version ——————————-

Willing to install Qt4 & QtCreator on my fresh installed fedora 16, I have gone into some trouble…, at my first compilation attempt (« run qmake » attempt, actually), a surprising error pops-up :

/usr/share/qt4/mkspecs/linux-g++/qmake.conf.

After a quick and unsuccessful search on Google, I decided to make a quick search on my hard disk on « mkspecs » and I found that it seems to be in fact in /usr/lib64/qt4/mkspecs.
In a naive attempt, I try the symlink, thinking of a 64bits a bit bad-managed by the libraries paths :

sudo ln -s /usr/lib64/qt4/mkspecs /usr/share/qt4/mkspecs

Well… it works !! Issue solved, it seems, it even compiles !
If you have any additional information / solution, please feel free to add it in the comments below !

Et là, plus de wifi…

Après avoir cherché des heures et des heures à bidouiller avec modprobe etc… j’ai regardé mon dmesg :

[ 239.100501] iwl3945 0000:06:00.0: iwlwifi-3945-2.ucode firmware file req failed: -2
[ 239.103276] iwl3945 0000:06:00.0: iwlwifi-3945-1.ucode firmware file req failed: -2
[ 239.103281] iwl3945 0000:06:00.0: Could not read microcode: -2
[ 345.378949] iwl3945 0000:06:00.0: iwlwifi-3945-2.ucode firmware file req failed: -2
[ 345.382280] iwl3945 0000:06:00.0: iwlwifi-3945-1.ucode firmware file req failed: -2
[ 345.382284] iwl3945 0000:06:00.0: Could not read microcode: -2

J’ai donc cherché si un driver correspondait, visiblement, je n’avais pas le bon ! (alors que lsmod me renvoit bien iwl3945 !)

yum search 3945
Repository google-chrome is listed more than once in the configuration
===================================================================== N/S Matched: 3945 =====================================================================
iwl3945-firmware.noarch : Firmware for Intel® PRO/Wireless 3945 A/B/G network adaptors

Il faut donc installer le paquet « iwl3945-firmware » :

(en root)
yum install iwl3945-firmware

Et voilà ! Maintenant, vous faites :

su
ifup wlan0

Et votre LED Wifi va enfin, enfin, enfin s’allumer .

Générer la clé : 10 secondes
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/thouveni/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/[utilisateur]/.ssh/id_rsa.
Your public key has been saved in /home/[utilisateur]/.ssh/id_rsa.pub.
The key fingerprint is:

La « propager » : 10 secondes :
$ cat $HOME/.ssh/id_rsa.pub | ssh [utilisateur@]machine "mkdir -p .ssh; chmod 700 .ssh; cat >> .ssh/authorized_keys"
Note : si vous utilisez un port particulier (comme le port 42 par exemple), il faut rajouter « -p 42″ AVANT la commande entre guillemets, et APRÈS « [utilisateur]@machine » (entre les deux)

Tester que ça marche : 10 secondes
ssh [utilisateur@]machine

Enjoy

———————————– For our English readers : ———————————-

Not only it’s more secured, but much more praticle as well, here is how to configure in 30 seconds (timer in hand !) your SSH access to your favourite server using a RSA key instead of an old-fashionned password which is either not secured either secured but impossible to remember !

Generating the key: 10 seconds
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/[user]/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/[user]/.ssh/id_rsa.
Your public key has been saved in /home/[user]/.ssh/id_rsa.pub.
The key fingerprint is:

« Broadcasting » it: 10 seconds
$ cat $HOME/.ssh/id_rsa.pub | ssh [user@]host "mkdir -p .ssh; chmod 700 .ssh; cat >> .ssh/authorized_keys"
Note : if you use a specific port (as for instance the 42 one), you have to add « -p 42″ BEFORE the command in quotes, and AFTER « [user]@host » (between the two)

Testing it works: 10 seconds
ssh [user@]host

Enjoy

As usual, for international readers, the english version is below, at the end of the French version

Alors, on va encore m’accuser de publier que des billets geeks, et court pour celui-ci en plus, mais c’est tellement galère à chercher sur le net, que je ne peux m’empêcher de partager cette astuce avec vous

Passons aux choses intéressantes : Il peut être intéressant, voire indispensable (et ça vous intéressera majoritairement dans le cas où c’est indispensable, n’est-ce pas ) de pouvoir utiliser une vieille version de autoconf, notamment la fameuse 2.13, à la place votre super version hyper à jour utilisée par votre système GNU/Linux. Cependant, la question toute bête : bordel comment on fait pour dire à buildconf d’utiliser une autre version que celle par défaut du système ?

Eh bien, si vous avez passé une heure à chercher sur internet avant d’atterrir ici, vous allez être peut-être un peu déçu par la simplicité de la chose, mais bon, on n’échappe pas aux lois de Murphy ! :

export PHP_AUTOCONF=`which autoconf-2.13`

Note : ceci est l’exemple pour la compilation de PHP, pour la compilation d’un autre programme cela ressemblera très certainement à cela, je ne peux cependant pas donner de généralité !

Voilà c’est fini. Il suffit de taper cela dans votre console juste avant d’exécuter la commande « ./builconf » (ou généralement « ./buildconf –force » mais peu importe). Attention, cependant, vous devez taper cette commande et celle du buildconf dans la même console, évidemment.

J’espère que vous vous sentez soulagés Notamment si vous étiez en train d’essayer d’installer…humm… php depuis les sources ?

Merci à MaGeekGuy pour l’astuce

————————————————————————————————-

Well, I’m going to be again accused to publish only geek articles, and moreover, short, for this one, but it’s such a real pain to find that on the Internet, then I can’t resist to share it with you folks

Interesting things now : It can be useful, not to say essential (and it will interest you more in the case it’s essential, won’t it ) to be able to use an old version of autoconf, for exemple the famous 2.13, instead of your state-of-the-heart version used by default by your GNU/Linux operating system. However, what a stupid question : how the hell do you explain to buildconf that it must use an older version instead of the default one ?

Well, if you’ve just spent about an hour searching on the Internet before coming here, you may be a bit disapointed by the simplicity of the solution. But, after all, no one escape from Murphy’s laws ! :

export PHP_AUTOCONF=`which autoconf-2.13`

NB : this is an example for PHP compilation, for other soft compilation it will certainly be much like that, but I can’t exhibate a general case here.

Voilà, it’s over ! You now only need to type that in your shell just before the « ./buildconf » command (or more often « ./buildconf –force » but it doesn’t really matter). Beware, however, you must type this command in the same shell as the buildconf one, obviously.

I hope you feel distressed Specifically if you were trying to install…well… php from the sources ?

Thanks to MaGeekGuy for this tip .

Après avoir fait joujou une première fois avec les tâches planifiées sous cron gnu/linux, je vous avais promis de vous en dire plus sur les procédés et les possibilités du système de planification des tâches de GNU/Linux : cron.

Résumé de ce que vous savez déjà faire si vous avez lu la première partie sur les tâches planifiées cron :

• Créer une tâche planifiée simple qui lance un fichier exécutable avec l’utilisateur courant (celui qui a créé le cron) à l’aide la commande crontab
• Faire des tâches planifiées à exécution unique (planification non régulière/récurrente)
• (Utiliser un autre éditeur pour la commande crontab -e)

Ce que je vais vous apprendre en plus dans cet article :

• Gérer des dates complexes : Répétitions, récurrence des tâches planifiées (jokers, répétitions, sélections multiples)
• Définition d’un fichier personnalisé de tâches planifiées
• Définir une tâche exécutée par un utilisateur précis.
• Éxécuter une tâche planifiée dans un répertoire particulier.
• Éxécuter une tâche planifiée graphique.
• Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Je vous donnerai également quelques filons pour l’utilisation de PHP avec CRON.

Retour sur la planification des tâches : la syntaxe des dates avancées avec CRON.

Je ne refais pas les explications sur les dates simples dans CRON, c’est le sujet de la première approche (dont vous avez les liens au début de cet article). Nous allons voir comment créer une tâche récurrente, à l’aide des jokers, répétitions et sélections multiples.

Le joker : *

Comme dans beaucoup d’applications informatique, le joker chez Cron est l’étoile « * ». Ainsi, si vous remplacez un quelconque paramètre d’une date par une étoile, cela signifie pour cron « quelque-soit la valeur de ce paramètre ».

Exemple : Quelque-soit le jour, je veux que à 7h05 tu dises bonjour, durant tout le mois de février :

05 07 * 02 * echo 'Hello World !'

Ici nous avons remplacé le numéro du jour dans le mois, ainsi que le jour de la semaine (qui est également susceptible de varier !) par le joker « * », ainsi, quelque-soit les valeurs de ces paramètres, si les autres paramètres (heure, minute, mois) sont vérifiés, CRON dira bonjour au monde.

La répétition : /

Le joker permet de spécifier, au maximum, une répétition toutes les unités de temps d’un paramètre précis. En effet, si je mets un joker pour l’heure, alors cela sera exécuté toutes les une heure, puisque cela sera « quelque-soit l’heure ». Ainsi, avec les jokers, vous pouvez répéter au mieux : tous les jours, toutes les heures, toutes les minutes, tous les lundis, tous les mois… Bref, pas terrible comme flexibilité tout de même. C’est à cela que sert la répétition, elle vous permet de dire tous les combien de variation d’un paramètre vous voulez que cela se répète. Une variation d’un paramètre, c’est +1 minutes, +1 heure, +1 jour, etc. …

L’opérateur de répétition s’utilise comme suit : valeur_param/intervalle_de_repetition

Ainsi, si je veux que toutes les 15 minutes, une action se répète, quelque-soit la date :

*/15 * * * * /usr/bin/monaction

On utilise ici également le joker, puisque l’action se répète quelque-soit la minute, l’heure, ou la date…

Les intervalles et les sélections multiples

Vous pouvez également définir plusieurs valeurs d’un paramètre pour lesquelles la tâche sera exécutée. On procède soit en donnant un intervalle de valeurs, soit une liste de valeurs.

Opérateur d’intervalle : -

Utilisation : borne1-borne2 ou borne1 et borne2 sont les bornes de l’intervalle ( [borne1 ; borne2] ) et incluses.

Exemple : La précédente action se répète toutes les 15 minutes, du 1er au 10 du mois

*/15 * 1-10 * * /usr/bin/monaction

Opérateur de valeurs multiples : ,

Utilisation : valeur1, valeur2, valeur3…

Exemple : La précédente action se répète toutes les 15 minutes mais seulement entre 02h et 03h puis entre 05h et 06h

*/15 2,5 * * * /usr/bin/monaction

Définir une fichier cron personnalisé : Cron en mode admin

Jusqu’à présent, vous avez utilisé la commande crontab afin de modifier votre fichier cron et d’ajouter ou de supprimer des tâches.

En réalité vous n’avez utilisé que le côté « utilisateur » de cron. La suite n’est ouverte qu’à un accès root, autrement dit l’administateur de la machine, car elle permet notamment de décider de sous quel utilisateur vont être exécutées les tâches, ce que nous verrons en même temps.

Si ce mode d’utilisation de cron n’est réservé qu’à l’administateur, c’est pour plusieurs raisons :

1. Il va permettre, comme je l’ai dit, de choisir l’utilisateur qui exécute la commande
2. Le répertoire dans lequel nous allons créer le fichier appartient à root
3. Seul root peut demander à cron de recharger les fichiers de configuration, or nous en aurons besoin car comme nous allons éditer de simples fichiers, la commande crontab ne sera pas là pour, à la fin de l’édition du fichier, dire à cron « Hey hey, ouhou, on a modifié le fichier là, viens y jeter un coup d’oeil » et par défaut cron ne verra donc pas vos modifs sans reload, et donc sans droits d’admin.

Créer votre fichier de tâches planifiées : le répertoire /etc/cron.d/

Vous êtes donc maintenant loggé en root, ou, si vous n’avez pas le su sur votre machine, vous exécuterez le reste des commandes avec un « sudo » devant.

Les fichiers de tâches planifiées sont placés dans le répertoire /etc/cron.d/, qui appartient à root.

Créons-y un fichier :

vim /etc/cron.d/monfichiercron

Voilà, tout le travail est fait… ou presque. Dans ce fichier, vous pouvez placer des tâches planifiées exactement de la même façon qu’avec la commande crontab à la différence prêt… qu’il faut spécifier l’utilisateur d’exécution !

Cela donne :

mm HH JJ MM joursemaine utilisateur /chemin/commande

Exemple, je suis l’utilisateur Troll, je veux que l’utilisateur Toto fasse le ménage dans son dossier personnel chaque semaine (vision geek du Range ta chambre ! maternel/paternel), on dira qu’on est un peu radical, si le dimanche il n’a pas vidé son dossier perso (il est censé le faire le samedi) tant pis : tout poubelle !
Note : A NE PAS TESTER CHEZ VOUS ! Vous risqueriez d’avoir de sérieux ennui ^^

01 00 * * sun toto rm -fR /home/toto/*

Bien sûr l’utilisateur peut aussi être root… But, be careful !

Ensuite, une fois que vous avez sauvegardé votre fichier, il faut dire à cron de le relire pour l’intégrer :

(encore une commande à faire en root, si vous avez bien lu le début de ce paragraphe !)
/etc/init.d/crond reload

Cron a bien rechargé s’il dit ça normalement :

Reloading crond: [ OK ]

Les autres fichiers préconfigurés de cron :

Cron a également des dossiers préconfigurés, dans lesquels il vous suffit de mettre un script (ou un lien symbolique, solution la plus souvent utilisée) exécutable.

Ces dossiers sont les suivants :

• /etc/crond.daily : exécution quotidienne (chaque jour à 4h02)
• /etc/crond.hourly : exécution chaque heure (chaque heure + 1 minute)
• /etc/crond.weekly : exécution hebdomadaire (le dimanche à 4h22)
• /etc/crond.monthly : exécution mensuelle (le 1er du mois à 4h42)

Comme je suis gentil, je vous donne même les commandes :

Création d’un script exécutable dans un dossier :
(en root encore et toujours)
vim /mon/chemin/de/fichier && chmod +x /mon/chemin/de/fichier

Création d’un lien symbolique dans /etc/crond.daily (par exemple) pointant vers /mon/chemin/de/fichier :

ln -s /mon/chemin/de/fichier /etc/crond.daily/monscript && chmod +x /etc/crond.daily/monscript

L’avantage du lien symbolique c’est que vous pouvez mettre votre script dans un dossier où vous le retrouvez et vous pouvez placer un lien dans plusieurs dossiers /etc/crond.XXX/ sans avoir à modifier tous les fichiers quand vous modifiez le script (principe du lien symbolique).

Éxécuter des tâches planifiées dans un répertoire particlier

Il peut s’avérer que vous ayiez besoin d’exécuter une commande qui va chercher des fichiers ou autres dans son répertoire courant et qui sera donc perdue si vous la lancez avec cron de la manière /chemin/commande

Pour cela, utilisez tout simplement la commande cd :

03 01 * * * tutu cd /home/tutu/scripts/ && ./macommande

Éxécution d’une tâche planifiée graphique

La console, y’a rien de mieux, ça plante pas, ça vous cache rien… Mais c’est pas très esthétique. Puis si vous voulez par exemple lancer Amarok pour vous reveiller en musique, Amarok va avoir besoin d’une interface graphique (sauf si vous connaissez une interface ligne de commande pour amarok, auquel cas je veux bien que vous partagiez l’info avec moi !).

Pour cela, procédez comme suit : placez DISPLAY=:0 après le jour de la semaine, ou après le nom d’utilisateur quand celui-ci est spécifié.

Si vous utilisez une commande composée, du type :

/chemin/premierecommande && /chemin/deuxiemecommande

(ce qui est notamment le cas lorsque vous exécutez dans un répertoire particulier) alors vous devez mettre le DISPLAY=:0 juste avant la commande qui aura besoin de l’affichage.

Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Par défaut, notamment lors de la définition d’une tâche planifiée avec crontab -e, si votre commande génère une sortie vous devez – en théorie (désactivé sur certaines distrib’) – recevoir un « mail » ( dans /var/spool/votrelogin ) avec la sortie générée.

Ce n’est pas vraiment un mode très pratique pour logger et retrouver les sorties de vos tâches planifiées préférées.

Je vais donc vous montrer comment enregistrer dans un fichier log la sortie de vos tâches planifiées.

En fait, cela revient au même que pour enregistrer dans un fichier log une commande console standard. Cela revient à faire comme ceci :

Enregistrer tout dans monfichier.log (sortie normale + erreurs)
/chemin/macomandequigenereunesortie > monfichier.log 2>&1

Enregistrer seulement les erreurs dans monfichier.log :

/chemin/macomandequigenereunesortie > /dev/null 2> monfichier.log

Ne rien enregistrer :

/chemin/macomandequigenereunesortie > /dev/null 2>&1

Attention, tel que c’est présenté ici, chaque nouvelle exécution remplace le contenu de monfichier.log

Si vous voulez logger sur plus d’un seul lancement, vous devez créer le fichier monfichier.log avant (ce qui n’était pas nécessaire précédemment) et remplacer systématiquement dans les précédentes commandes, le « > » par « >> » (enfin presque, pas tous, regardez ci-dessous).

Ce qui donne :

/chemin/macomandequigenereunesortie >> monfichier.log 2>&1
/chemin/macomandequigenereunesortie > /dev/null 2>> monfichier.log
/chemin/macomandequigenereunesortie > /dev/null 2>&1

Annexes : Utilisation de PHP avec CRON

Pour lancer une tâche écrite en PHP avec cron, saisissez une tâche de la manière suivante :

mm HH JJ MM joursemaine [user] /usr/bin/php -f /chemin/de/fichier.php

Ou, ce qui est conseillé avec PHP, avec exécution dans un repértoire particulier :

mm HH JJ MM joursemaine [user] cd /chemin/de/ && /usr/bin/php -f ./fichier.php

Bien évidemment, vous pouvez logger dans un .log avec les .php comme avec n’importe quelle autre commande.

Voilà, c’est terminé : des remarques, des erreurs à signaler, des questions -> Les commentaires sont là pour ça ! J’espère avoir été clair et que cet article sera utile au plus grand nombre

Article original :
Salut la compagnie,

Aujourd’hui, et malgré les touffes de poils que le Troll s’est arrachées toute la journée en se battant avec le fameux vilain cron et son accolite crontab, je vais vous parler de quelque-chose de bien utile, voire tout simplement indispensable, pour n’importe quel administrateur d’un serveur web, ou même d’un site internet (mais il est assez rare que vous ayiez la possibilité de mettre des cron sans avoir un dédié (ou au moins un VPS) ) : les tâches planifiées.

Les tâches planifiées c’est quoi ? Que vous soyiez GNU/Linuxien ou Windowsien (bouuuuuuh, bon ok, j’arrête) vous ne le savez peut-être pas mais votre système est capable de faire des choses sans que vous lui demandiez, sans que vous n’ayiez quoi que ce soit à faire, de manière automatique.

Cela s’appelle les tâches planifiées , concrètement cela signifie qu’une tâche, va être planifiée (jusque-là, vous suivez ?), et qu’une fois que c’est fait, elle s’exécutera de manière automatique soit une fois, soit plusieurs fois, suivant la manière dont on la planifie.

Planifier ? Késako ?

Tout d’abord, considérons que vous n’avez jamais eu à faire à ce genre de choses, et partons du début : Planifier ? Késako ? (si vous n’avez jamais vu ce mot… euh… je plains votre patron) Planifier, cela signifie que l’on va fixer une date, une heure, un moment précis, où l’on souhaite exécuter une tâche.

Si c’est une tâche unique, que l’on a besoin d’effectué qu’une seule fois, parce-qu’on est pas là à ce moment-là par exemple (comment que vous programmiez votre magnétoscope pour enregistrer le film débile du samedi soir (pour vos enfants bien sûr… vous, vous ne regardez rien de stupide, Arte©® Powered, n’est-ce pas ?) ).

Si c’est une tâche récurrente c’est-à-dire qu’il faudra l’exécuter régulièrement (comme faire le ménage !), dans ce cas il sera possible de la programmer de manière à ce qu’elle s’effectue de manière récurrente, toujours au même moment, à la même heure, etc. … (et de la même façon, on a à faire à des ordinateurs standards, pas d’IA encore).

Cron & Crontab : Je planifie, tu planifies…

Sous Linux, le principal outil de planification se nomme cron, et très vite nous (et vous aussi) appelerons tout simplement une tâche planifiée un cron.

Tout d’abord, avez-vous cron d’installé ? Cron est installé sur un bon 80% des distributions, donc il y a des chances. Pour le savoir tapez :

ls -l /etc/init.d/ | grep cron

Pour ceux sous archlinux, /etc/init.d c’est /etc/rc.d/ de mémoire.

Si vous êtes sous un système basé sur debian, avec aptitude :

sudo aptitude show cron

Sous Fedora :

sudo yum install cron

(si cron est déjà installé ça vous le dira, sinon, ça l’installera !!)

Comme on est pas encore sûr que cron soit déjà lancé, faisons un petit restart :

sudo /etc/init.d/cron restart

(il est possible que le fichier soit nommé « crond » chez vous)

Bon, on est prêt, cron est lancé. Maintenant que faire ?

Dans cette première partie, comme c’est écrit dans le titre, je ne vais pas vous donner toutes les « clés » de cron, nous allons simplement voir ensemble comment utiliser la commande de base, qui permet en fait à elle seule de tout faire, juste d’un manière parfois moins « propre » qu’en passant par certains fichiers un peu plus « complexes » (pas vraiment complexes en fait, mais ça vous fais manipuler des fichiers etc. etc. … puis faut être root, alors ne commençons par les bêtises tout de suite).

La commande dont vous allez dorénavant tomber amoureux est la suivante :

crontab -e

La commande crontab permet, de manière générale, de mettre à jour et modifier les tâches cron d’un utilisateur donné.

Donnons tout de même quelques précisions dessus :

- Si vous voulez remplacer la totalité de votre crontab (c’est-à-dire toutes les tâches qu’il contient, comme nous allons le voir après) par le contenu d’un fichier, utilisez la commande comme ceci :

crontab /chemin/vers/mon/fichier

- Ensuite, par défaut la commande crontab va éditer le fichier crontab de l’utilisateur courant (oui, c’est vous qui courez),  si vous voulez modifier le crontab d’un autre utilisateur (notamment pratique quand on exécute la commande en root !!)  il faut lui préciser le paramètre « -u » comme ceci :

crontab -u user

- Et puis allez, un petit dernier pour la route, pour voir le contenu de votre crontab sans l’éditer (le « -e » que nous allons voir) :

crontab -l

Les paramètres peuvent bien entendus se combiner :

crontab -l -u troll

(affiche le contenu du crontab de l’utilisateur troll (c’est moi) )

Voilà, maintenant passons aux choses sérieuses, donc, l’édition :

crontab -e

Vous voilà maintenant dans un fichier texte, ne vous souciez pas de savoir où il est ni ce que c’est, car c’est en réalité un fichier temporaire.

Vous êtes certainement (95% de chance) sous l’éditeur en console « Nano« ,  si vous savez utiliser vim (ou vi pour les courageux) et que vous êtes (comme moi) allergiques à nano, je vous file quand même la magouille :

EDITOR="vim" crontab -e

Je me contenterai pour ma part de décrire les actions à faire sous nano, supposant que si vous utilisez vim, c’est que vous savez vous en servir (vraiment trèèèès compliqué… (ironie) ).

Dans ce fichier, vous mettrez une tâche planifiée par ligne, et UNE SEULE !

Suivant la longueur de votre « ligne » cell-ci peut s’afficher sur plusieurs « lignes » en console, mais tant que vous n’avez pas mis de retour ligne (Entrée) cela reste la même ligne. Lorsque qu’une ligne est trop longue pour être affichée en plein, nano la coupe en général et met un « $ » à la fin pour vous dire que tout n’est pas affiché.

Maintenant voyons la syntaxe des « cron » :  ceux-ci sont constitués de deux parties distinctes : le moment d’exécution, et la commande à exécuter (ou tâche). Les deux parties sont séparées par un espace (comme souvent sous GNU/Linux).

Ce qui donnera donc à la fin :

partie_date partie_tache

Voyons ce qu’on met à la place de partie_date (dans l’ordre, avec un espace entre chaque donnée à chaque fois) :

1. minute : la minute (00 à 60) de l’heure à laquelle exécuter la tâche
2. heure : l’heure (0 à 23), de l’heure de planification de la tâche
3. jour du mois : de 0 à 31 (ou autre, suivant les mois), le jour, dans la date de planification de la tâche
4. mois : nombre correspondant au mois (00 à 12) de la date à laquelle vous voulez planifier.
5. jour de la semaine : Le nom abrégé (mon, tue, wed, thu, fri, sat, sun) ou le numéro (1 à 7) du jour de la date de planification au sein de sa semaine : Lundi = 1, mardi = 2, etc…

Voilà, petit exemple, admettons que je veuille exécuter une date le 1er de l’an 2010 à une heure de l’après-midi, la partie « partie_date » sera la suivante :

00 13 01 01 fri

Vous devez avoir au total 5 données : minute heure jourdumois mois jourdelasemaine Voilà, pour la partie « date », nous nous contenterons des dates fixes dans cette première approches.

Venons-en à la tâche à éxécuter : Ici, rien de plus compliqué que de taper dans une console. Cron lira la tâche à exécuter avec bash, ce qui signifie qu’il le lira de la même manière (enfin presque) qu’il lit les choses quand vous, vous tapez dans la console.

Un petit détail cependant : mettez toujours toutes les commandes en chemin ABSOLU ! ! ! Même les commandes qui paraissent évidentes et qui sont dans /usr/sbin, rajoutez bien le /chemin/vers/mon/fichier .

Ce qui vous donnera, une fois les deux parties remplies :

minute jour jourdumois mois jourdelasemaine /chemin/vers/ma/commande

Maintenant que vous avez écrit votre tâche planifiée, il n’y a plus qu’à enregistrer et fermer !

Pour ça, faites CTRL + X, puis appuyez sur « O » pour répondre oui à la question, et enfin appuyez sur ENTREE pour confirmer votre « oui ».

Sous vi/vim : sortez du mode édition (CTRL + C) puis tapez le traditionnel :wq

Voilà, je vous écris très prochainement la partie suivante : seconde approche.

On y abordera : les jokers, les répétitions, les sélections multiples dans les dates.

Dans les tâches : comment gérer leur sortie et enregistrer leurs résultats et leurs erreurs, ou au contraire ne pas le faire, et ne pas recevoir de « mail » du logger. On parlera peut-être également de la modification manuelle des fichiers cron auxquels la commande « crontab » ne touche pas. Petite note : si vous avez un quelconque problème avec ces explications, laissez un comm’ pour demander de l’aide

Mise à jour : La deuxième partie de ce guide sur les tâches planifiées, intitulée Tâches planifiées sous Linux (cron, crontab) : Seconde approche est dorénavant disponible ici : tâches planifiées sous Linux (cron, crontab) : Gestion et commandes avancées.