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

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

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.