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

MySQL, c’est bien, c’est gratuit, c’est open, tout ça… Mais ça a ses limites, et notamment un tas de bugs.
Et puis en plus, depuis quelques temps, MySQL a un sacré inconvénient : Oracle.

Mais bon, c’est une longue discussion. Tout ça pour dire que si vous êtes ici c’est très certainement que vous êtes passé à MariaDB ! Très bon choix, je ne peux qu’approuver.

Cependant, notamment si vous êtes sous Debian (peut-être bien sous d’autres distros aussi), votre MariaDB va vous causer tout un tas de problèmes, notamment avec les CMS en vous renvoyant tout un tas d’erreurs que vous ne verriez jamais avec MySQL. C’est parce que le « strict mode » est activé par défaut dans MariaDB.

Et il est plutôt très difficile de comprendre comment le désactiver en cherchant sur Google… En effet les solutions que l’ont trouve nous proposent de modifier le fichier de conf et d’ajouter une ligne « sql_mode =  » etc. … Mais ça ne marche pas.

En fait, ça ne marche pas parce qu’il faut que cette ligne soit dans la section « [mysql] » de votre fichier de conf (qui s’appelle bien souvent my.cnf), sinon cela ne marchera jamais !!

Cherchez donc dans votre my.cnf ceci :

[mysql]

Et ajoutez juste en dessous cette ligne :
sql_mode ="NO_ENGINE_SUBSTITUTION,TRADITIONAL,NO_AUTO_CREATE_USER"

En vérifiant bien évidemment qu’il n’y a pas autre part dans le fichier une ligne « sql_mode=… » qui dit le contraire de ce qu’on vient d’ajouter.
Redémarrez MariaDB… Enjoy !

————- English version ———–

MySQL, it’s good, it’s free of charge, it’s open, etc. … But, it has some limitations, and particularly a certain amount of bugs.

Moreover, for a couple a months, MySQL has a serious drawback : Oracle.

But, well, it’s a long discussion. All of this to say that if you’re here reading this very post, it is likely that you’ve gone through MariaDB migration ! Very good choice, I’m forced to approve it.

Although, especially if you are using Debian (maybe in other distros too), your MariaDB will certainly cause you a couple of problems, especially with CMS, throwing lots of SQL errors you would never see with MySQL. It is because the « strict mode » is enable by default in MariaDB.

And it is really difficult to find out how to disable using your googling skills. Indeed the solutions we can find on the Internet suggest to modify the configuration fileto add a ligne « sql_mode=  » etc. … But this does not work.
In fact, this does not work because this ligne must be placed in the « [mysql] » section of your conf file (which is often named my.cnf), else this will never work !!

So, look for this in your my.cnf :

[mysql]

And add this line just after it :
sql_mode ="NO_ENGINE_SUBSTITUTION,TRADITIONAL,NO_AUTO_CREATE_USER"

Of course, checking that there is no other line « sql_mode=… » in the file saying the contrary of what we have just added.
Restart MariaDB… Enjoy !

La dédibox V3 est fraichement installée, rien ne tourne dessus, aucun paquet supplémentaire si ce n’est le logiciel hardinfo et ses dépendances pour le benchmark.

Tout d’abord, hdparm (débits disque) :

*:~# free -m
total used free shared buffers cached
Mem: 1980 228 1751 0 87 85
-/+ buffers/cache: 55 1924
Swap: 2047 0 2047
*:~# hdparm -t /dev/sda

/dev/sda:
Timing cached reads: 1358 MB in 2.00 seconds = 679.22 MB/sec


Espace disque et utilisation RAM à vide :

(j’ai choisir une partition de 2G de swap au lieu de 1G proposé par défaut)

Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda2 145G 1,8G 136G 2% /
tmpfs 991M 0 991M 0% /lib/init/rw
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
procbususb 0 0 0 - /proc/bus/usb
udev 10M 480K 9,6M 5% /dev
tmpfs 991M 0 991M 0% /dev/shm
devpts 0 0 0 - /dev/pts
/dev/sda1 190M 26M 155M 14% /boot

Maintenant, le bench HardInfo :

hardinfo
Computer
Summary
Operating System
Kernel Modules
Boots
Languages
Filesystems
Shared Directories
Display
Network Interfaces
Users
Devices
Processor
Memory
PCI Devices
USB Devices
Printers
Battery
Sensors
Input Devices
Storage
Benchmarks
CPU ZLib

-FPU Raytracing-
This Machine : 19,973
Intel(R) Celeron(R) M processor 1.50GHz : 40.8816714
PowerPC 740/750 (280.00MHz) : 161.312647

Voilà, bonne soirée

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 .

Connectez vous en console (SSH) ou FTP ou SFTP comme vous voulez, de manière à pouvoir accéder à tous les fichiers de DTC (donc soit avec l’utilisateur dtc soit en root).

Puis rendez-vous dans le dossier suivant :

/var/www/sites/

Maintenant rendez-vous dans le dossier correspondant à l’administrateur DTC qui gère le domaine où il y a l’adresse qui a cet ennui :

cd user

Puis dans le domaine de l’adresse concernée :
cd mondomaine.com/

Maintenant, entrez dans le dossier principal de l’adresse mail qui pose problème :
cd Mailboxs/adressemail/

« adressemail » correspond à ce qu’il y a avant le @ : tartanpion@mondomaine.net -> tartanpion.

Enfin, supprimez le fichier suivant :

rm -vf .vacation.db.gdbm

Voilà, votre problème devrait être résolu. Par contre plus de « répondeur automatique« , cependant vous pouvez essayez de le remettre en espérant que ça ne re-plantera pas.

Enjoy

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.