Project:Omega.org

Par Chris Stone

Traduit par Olivier, le 03/02/2003

Note de l’auteur — Dans la première partie de cette série concernant l’application Terminal de Jaguar, vous avez appris à modifier les tâches cron déclenchées par le système en modifiant le fichier crontab.

Dans cette seconde partie, je vous montrerai comment configurer cron afin qu’il vous envoie des emails chaque fois qu’une des tâches est déclenchée.

Si vous utilisez Mac OS X 10.1 (ou une version antérieure), veuillez vous référez à Apprentissage du Terminal de Mac OS X, Partie 1 qui est écrit pour ces versions de Mac OS X.

Premièrement, concentrons nous sur quelques lignes importantes du fichier /etc/crontab.
Puisque que vous souhaitez juste lire le fichier sans le modifier, vous n’avez pas besoin d’utiliser un éditeur de texte comme pico.
Au lieu de cela, pour afficher des petits fichiers, utilisez l’utilitaire cat, qui affiche la totalité du fichier dans la fenêtre puis se termine :

[haru:~] chris% cat /etc/crontab

Vous remarquerez peut-être quelques petites choses intéressantes à propos de cette commande.
Premièrement, puisque les droits d’accès sur /etc/crontab autorisent tout le monde à en faire la lecture (mais seul le root peut le modifier), l’utilisation de sudo est inutile.

Deuxièmement, cette commande vous permet d’accéder au fichier d’un répertoire autre que votre répertoire de travail en spécifiant, dans ce cas, le chemin d’accès complet (ou absolu) de ce fichier.
(Vous n’avez pas utilisé la commande cd vers /etc pour ouvrir crontab, comme vous l’aviez fait dans la première partie.)
Un chemin absolu décrit la hiérarchie du répertoire depuis l’origine du système de fichier (le répertoire racine ou “/”), jusqu’au fichier.

Enfin, comme certaines lignes de crontab pourraient être trop longues pour votre fenêtre, vous aurez peut-être besoin d’agrandir la fenêtre en la tirant par son coin inférieur droit jusqu’à ce que les lignes soient affichées sans retour à la ligne.

Regardez maintenant la ligne qui spécifie la tâche cron quotidienne, qui, selon votre configuration de date, vue en première partie, doit ressembler à quelque chose comme cela :

15    3    *    *    *     root   periodic daily

Juste après les cinq champs destinés à la date se trouve le champ utilisateur.
Dans ce cas, le champ utilisateur indique à cron d’exécuter la tâche comme s’il s’agissait de l’utilisateur root.
Cela est nécessaire parce que ces tâches de maintenance nécessitent l’accès total au système attribué à l’utilisateur root.

A la suite du champ utilisateur se trouve le sixième et dernier champ, qui contient la ligne de commande que cron passe au shell pour qu’elle soit exécutée.
Cette commande, periodic daily, indique à cron d’exécuter l’utilitaire periodic avec l’argument daily.

Les arguments d’une commande sont juste des éléments de texte supplémentaires associés à la commande, représentant des options, qui déterminent le comportement de la commande.
Dans ce cas, l’unique argument de periodic indique que periodic exécute sa tâche de façon quotidienne.

Periodic

Comme vous le verrez au fur et à mesure que vous pénétrerez dans le coeur Unix de Mac OS X, il y a beaucoup de partage de travail entre tous les utilitaires spécialisés du système.
Typiquement, pour que le système effectue une tâche importante, un utilitaire unique et simple effecutera sa part, puis il passera la main à un autre utilitaire qui effectuera le travail pour lequel il a été conçu.
Le principal devoir de cron, par exemple, est de déclencher l’exécution des tâches planifiées.
Cependant, son rôle n’est pas d’organiser, gérer les priorités ou générer un rapport d’éxecution de ces tâches (bien que cron peut effectuer certaines de ces choses, et en fait le faisait dans les versions de Mac OS X antérieures à 10.2).

Pour effectuer ces différents aspects de tâches de maintenance de routine, cron fait appel à periodic, un utilitaire conçu spécialement pour exécuter ce genre de tâches systèmes.
Dans ce cas, l’argument daily passé à periodic fait référence à un répertoire du même nom.
Le répertoire daily existe dans /etc/periodic, un endroit où periodic sait trouver les fichiers exécutables à lancer.
A l’intérieur de /etc/periodic/daily, se trouvent les scripts shell qui effectuent les tâches de maintenance quotidienne.

Un script shell est un fichier contenant une série de lignes de commandes qui peuvent être exécutées en mode batch par le shell.
Un peu comme un AppleScript, un script shell vous permet de créer et sauvegarder de longues procédures automatisées que vous pouvez exécuter à n’importe quel moment en utilisant une seule ligne de commande.

Si vous voulez jeter un coup d’oeil au contenu du répertoire /etc/periodic, vous pouvez le faire en utilisant ls et son option -R (pour lister de manière récursive), comme cela :

[haru:/etc/periodic] chris% ls -R /etc/periodic
daily   monthly weekly

/etc/periodic/daily:
100.clean-logs 500.daily

/etc/periodic/monthly:
500.monthly

/etc/periodic/weekly:
500.weekly

L’option -R affiche le contenu de ce répertoire ainsi que celui de ses sous-répertoires, en traversant toute la hiérarchie.

Comme vous pouvez le voir, il y a trois répertoires dans /etc/periodic : daily (quotidien), weekly (hebdomadaire) et monthly (mensuel).
A l’intérieur de chacun il existe au moins un script shell (daily en à deux), dont le nom commence par trois chiffres.
Ce nombre indique l’ordre dans lequel periodic doit exécuter les scripts, les plus petits nombres étant les premiers (100.clean-logs sera exécuté avant 500.daily).

Nous verrons ces scripts plus en détails dans la troisième partie de cette série, mais la prochaine étape est de configuer l’agent de transfert mail sendmail intégré à Mac OS afin qu’il s’exécute correctement, puis configuer periodic afin qu’il vous envoie un email du rapport générée par chaque script.

sendmail

Les agents utilisateurs de mail (MUA en anglais) sont ces applications qui vous permettent d’envoyer, recevoir et effectuer d’autres tâches relatives aux courriers électroniques.
Outlook, Eudora et l’application Mail de Mac OS X sont des exemples familiers de MUAs.

En revanche, les agents de transfert de mail (MTAs en anglais) ne sont pas des applications aussi familières.
Elles reçoivent les messages du MUA et les passent aux autres utilisateurs de la même machine, ou à d’autres MTAs sur d’autres machines pour atteindre les utilisateurs plus distants.
Le MTA sendmail inclus dans Mac OS X est l’un des plus populaires, utilisé sur de gros et petits serveurs à sur internet.

La procédure qui suit montrera la marche à suivre pour faire fonctionner sendmail sur votre machine pour qu’il puisse délivrer les rapports générés par periodic.
Pour obtenir de l’aide pour faire fonctionner sendmail dans un environnement serveur, voyez cet article.

La première étape pour que sendmail se lance correctement sur Mac OS X est de s’intéresser au problème des droits d’accès.
Par mesure de sécurité, sendmail ne s’exécutera pas avec les droits d’accès par défaut du répertoire racine.

Eliminer les Erreurs de Droits avec sendmail

Il existe actuellement deux manières d’adresser ce problème.
La première et la plus évidente est de simplement changer les droits, et autoriser sendmail à s’exécuter.
L’autre solution, moins évidente, est de configurer sendmail de sorte qu’il ignore les droits d’exécution problématiques et s’exécute.

La première solution consiste en une simple modification : supprimer les droits d’écriture au niveau du groupe sur le répertoire root.
La commande permettant de facilement visualiser et modifier les différents droits d’accès de chaque élément est simple, mais les modifications sont trop importantes pour les détailler ici. (Bien sûr, dans Mac OS X : The Missing Manual vous trouverez une explication approfondie des droits d’accès et de la ligne de commande.)

Je vais faire les choses simplement en vous donnant une commande simple qui permettra à sendmail de fonctionner :

sudo chmod g-w /

Puisque vous modifiez les droits d’accès du répertoire racine, la commande doit commencer par sudo.
Puis vient la commande chmod, pour “changer les modes (des fichiers).”
Les modes de fichiers sont des attributs qui spécifient si l’élément peut être lu ou modifié, par exemple, et par quel type d’utilisateur — le propriétaire du fichier, son groupe, ou n’importe quel utilisateur de la machine. (Ces attributs correspondent, bien sûr, aux attributs de Propriété et Droits d’Accès qui sont disponibles depuis la fenêtre Information du Finder.)

A la suite de l’espace se trouvent les arguments de chmod, le premier spécifiant le mode à changer.
Cet argument précise de prendre le groupe (”g“) et de supprimer (”-“) le droit en écriture (”w“) sur le fichier ou répertoire spécifié par l’argument suivant (lui aussi après l’espace), qui dans ce cas est le répertoire racine, (”/“).

La prochaine étape est d’exécuter la commande :

[haru:~] chris% sudo chmod g-w /

[haru:~] chris% sudo chmod g+w /

Il existe une bonne raison pour laquelle Apple souhaite que le répertoire racine soit modifiable par le groupe.
De nombreux installateurs d’applications Classiques (et même quelques natives) sont implémentés pour placer leurs éléments au niveau du répertoire racine, et à moins de donner à ces applications les droits administrateurs pour le faire, elles ne réussiront pas à s’installer.
Pour éviter ce problème, Apple a laissé les droits d’accès en écriture pour le groupe sur le répertoire racine.

Bien sûr, cela pause problème à sendmail qui, pour des raisons de sécurité, a besoin que ces droits soient enlevés.
A ce point, vous ne devez plus savoir trop que faire.
Ne serait-il pas plus simple de pouvoir dire à sendmail, “Je veux bien perdre un peu de sécurité si tu me donnes la permission de garder mes droits !”

En fait, sendmail vous permet cette option par l’ajout d’une seule ligne dans son fichier de configuration.
Ce passage est tiré de la documentation de sendmail :

Vous souhaiteriez peut-être modifier votre environnement pour le rendre plus sûr pour l’exécution de sendmail.
Si vous considérez que certaines options sécurité de sendmail sont trop restrictives pour votre environnement, vous pouvez les annuler par l’option DontBlameSendmail.
L’option est bien nommée puisque vous ne devrez pas blamer sendmail pour des problèmes résultants d’une faille de sécurité sur vos répertoires et fichiers.”

Tant que vous utilisez sendmail de la manière indiquée dans ce tutoriel et que vous êtes l’utilisateur principal de la machine, il y a peu de risque au niveau de la sécurité en utilisant cette option.
Si, par contre, vous ne pouvez plus avoir accès à votre machine en local ou à distance, et que vous êtes bloqués, je compte sur vous pour ne pas m’en vouloir non plus

Donc si cette méthode vous semble plus appropriée que la première (qui utilise sudo chmod g-w /), alors vous devez éditer le fichier /etc/mail/sendmail.cf.
Faites-en d’abord une sauvegarde.
Puisque le répertoire /etc/mail n’est modifiable que par le root, vous devez utiliser sudo :

sudo cp -p sendmail.cf sendmail.cf.bak

Vous remarquerez l’utilisation de l’option -p dans cette commande, qui préserve les droits du fichier d’origine dans la copie.
Cela rendra les choses plus simples si vous devez rapidement restaurer ce fichier.

Vous pouvez éditer le fichier en utilisant pico, comme vous l’avez fait avec d’autres.
Puisque sendmail.cf n’est modifiable que par le root, vous devez, ici aussi, utiliser sudo.

sudo pico /etc/mail/sendmail.cf

Ce fichier fait environ 1200 lignes et peut paraître intimidant, mais puisque nous allons juste ajouter une ligne près du début puis en ressortir rapidement, vous ne devriez pas vous faire de soucis.

En regardant ce fichier, rappelez-vous que les lignes commençant par le caractère # sont ignorées par sendmail.
Typiquement, ces lignes représentent des commentaires descriptifs des paramètres de configuration, mais ils peuvent également être des paramètres qui pour des raisons diverses sont à ignorer par sendmail lors de son initialisation.

La ligne que vous rechercher est la ligne commentée “DontBlameSendmail”, située à environ 70 lignes du début.
La façon la plus rapide d’y accéder avec pico est en pressant Control+W, taper DontBlame, et appuyer sur la touche Entrée.
Vous devriez voir ces lignes :

# level 10 config file format
V10/Berkeley

# override file safeties - setting this option compromises system security,
# addressing the actual file configuration problem is preferred
# need to set this before any file actions are encountered in the cf file
#O DontBlameSendmail=safe   

# default LDAP map specification

A la suite de cette ligne, ajouter la ligne suivante :

O DontBlameSendmail=GroupWritableDirPathSafe

Une fois terminé, vous devriez obtenir :

# override file safeties - setting this option
# compromises system security, addressing the actual
# file configuration problem is preferred
# need to set this before any file actions are
# encountered in the cf file
#O DontBlameSendmail=safe
O DontBlameSendmail=GroupWritableDirPathSafe
# default LDAP map specification

Comme d’habitude, appuyez sur Control+O pour sauvegarder le fichier, Entrée pour confirmer le nom, et Control+X pour quitter pico.

Si tout s’est bien passé, sendmail devrait
tenter d’envoyer un email la prochaine fois qu’on le lui demande, même
si le répertoire racine a des droits d’accès modifiables en écriture
pour le groupe.

NetInfo et sendmail

La version de sendmail intégrée à Mac OS X est compilée de manière à interroger la base de données de NetInfo pour ses informations de configuration ou un lien sur un fichier de configuration.

Dans notre cas, nous voulons que sendmail lise depuis
le fichier /etc/mail/sendmail.cf donc vous aurez besoin
d’ajouter un enregistrement désignant ce fichier dans la base de données
de NetInfo. Pour ce faire, utilisez la commande niutil
avec ces deux commandes :

sudo niutil -create . /locations/sendmail
sudo niutil -createprop . /locations/sendmail sendmail.cf /etc/mail/sendmail.cf

niutil, ou NetInfo Utility, est la version texte de l’application graphique NetInfo Manager que l’on trouve dans /Applications/Utilities.
La première ligne de commande crée un nouvel enregistrement, et la seconde écrit les propriétés de cet enregistrement : le nom du fichier de configuration et son chemin.

A partir de maintenant, quand sendmail interroge NetInfo pour son fichier de configuration, il recevra un pointeur sur ce nouvel enregistrement, et accédera à /etc/mail/sendmail.cf pour en lire le contenu.

Une Chose à Propos de sendmail

La dernière étape concernant sendmail est de le configurer pour qu’il démarre lorsque la machine démarre.
sendmail continuera alors de tourner en tâche de fond tant que la machine fonctionne, à l’écoute de nouveaux courriers à délivrer et s’assurant que les messages non délivrés ne s’accumulent pas.
De tels processus tournant en tâche de fond (souvent appelés démons), jouent un rôle vital dans les opérations de Mac OS X, et la plupart du temps utilisent très peu de mémoire ou de ressources processeur.

Bien qu’il ne soit pas nécessaire de faire tourner sendmail en tant que démon pour les besoins de ce tutoriel, le faire permettra de s’assurer que le ménage au niveau du mail sera bien effectué.
La configuration nécessite une action simple : effectuer un changement dans le fichier /etc/hostconfig.

Ouvrez le fichier dans pico comme d’habitude (mais vous voulez peut-être vous assurer d’en faire une sauvegarde avant) en utilisant sudo puisqu’il s’agit d’un fichier appartenant à l’utilisateur root.

sudo pico /etc/hostconfig

Recherchez la ligne :

MAILSERVER=-NO-

Et changez juste le NO en YES, ce qui donne :

MAILSERVER=-YES-

Sauvegardez le fichier et fermez pico comme d’habitude, et votre serveur de mail sendmail démarrera à chaque boot.
Puisque sendmail ne tourne pas encore sur votre machine, vous pouvez le démarrez sans rebooter en utilisant la commande :

sudo /System/Library/StartupItems/Sendmail/Sendmail start

Cette commande exécute le même script de démarrage de sendmail que le système lorsque MAILSERVER est initialisé à YES dans /etc/hostconfig.

Vérifier le Courrier

Maintenant que sendmail est prêt, il est temps de le tester en envoyant un courrier depuis la ligne de commande.
Pour ce faire, utilisez la commande mail pour vous envoyez un courrier de la manière suivante (remplacez chris par votre nom utilisateur) :

[haru:~] chris% mail chris
Subject:

Vous êtes maintenant à l’intérieur de l’application en mode texte mail, donc vous ne verrez plus l’invite du shell tcsh jusqu’à ce que vous quittiez mail.
Tapez n’importe quoi pour le sujet et appuyez sur la touche Entrée.
Tapez votre message. Pour terminer votre message, l’envoyer et quitter mail, appuyez sur la touche Entrée, tapez un point, et appuyez sur la touche Entrée de nouveau.
Vous retrouverez alors l’invite du shell :

[haru:~] chris% mail chris
Subject: Test
This is only a test.
.
EOT
[haru:~] chris%

Vous pouvez vérifier votre courrier en entrant la commande mail de nouveau, mais cette fois sans arguments.
Si le message est arrivé, vous verrez quelque chose comme :

[haru:~] chris% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/mail/chris": 1 message 1 new
>N  1 chris         Fri Jan 17 13:50  13/399   "Test"
&

Vous vous retrouvez de nouveau dans l’application mail, mais cette fois pour lire votre nouveau message.
Appuyez sur la touche Entrée à l’invite “&” pour l’afficher :

Message 1:
From root  Fri Jan 17 13:50:30 2003
Date: Fri, 17 Jan 2003 13:50:30 -0800 (PST)
From: Chris Stone <chris>
To: chris
Subject: Test

This is only a test.

&

Tapez q puis Entrée pour quitter mail :

& q
Saved 1 message in mbox
[haru:~] chris%

tail /var/log/mail.log

De Retour à Periodic

Maintenant que votre MTA fonctionne, il reste peu d’étapes pour faire en sorte que periodic puisse vous envoyer des rapports.
La première est de configurer periodic pour envoyer ces rapports à l’utilisateur root au lieu de les sauvegarder dans des fichiers.
La seconde étape est de configurer l’ensemble pour s’assurer que tout courrier envoyé à l’utilisateur root soit renvoyé sur votre compte.

Pourquoi l’utilisateur root ?
En fait, nous pourrions faire en sorte que periodic envoie les rapports directement sur votre compte, et cela fonctionnerait bien.
Mais c’est une pratique standard sur Unix que tout courrier généré par le système soit envoyé à l’utilisateur root, car on est certain que ce compte utilisateur existe.
Il est ensuite assez simple de modifier l’adresse de redirection du compte root une seule fois, plutôt que plusieurs fois au cas où l’adresse de destination (la vôtre dans ce cas) devait changer plus tard.
Cependant pour l’instant, il est peu probable que vous receviez des courriers systèmes d’autres processus que periodic, mais tout serait prêt si cela devait arriver.

periodic lit le fichier de configuration depuis le fichier /etc/defaults/periodic.conf.
Nous ne modifierons pas ce fichier, mais en prendre connaissance pourra être instructif.
Le fichier /etc/defaults/periodic.conf est un peu trop long pour être utilisé avec cat, donc vous utiliserez une application qui peut afficher les fichiers page par page.
Ce genre d’application s’appelle un pager, et le plus connu est more.

Tapez more et le chemin du fichier pour faire apparaître la première page du fichier.
Pour voir le fichier de configuration par défaut de periodic, tapez :

more /etc/defaults/periodic.conf

Vous devriez voir apparaître quelque chose comme :

Pour vous rendre à la page suivante, appuyez sur la barre espace. (Pour aller à la page précédente, appuyez sur la touche B, pour Back.)
Au bas de l’écran, vous verrez le nom du fichier en cours de visualisation, ainsi qu’un indicateur du pourcentage de fichier lu.
Pour en sortir, tapez Q (pour Quit).

En passant en revue le fichier, vous aurez remarqué trois sections principales d’options, une pour chacune des tâches de maintenance de periodic : daily, weekly et monthly.
Ce qui nous intéresse, c’est la ligne générée par chaque section. Par exemple, dans la section d’options daily vous trouverez cette ligne :

daily_output="/var/log/daily.out"  # user or /file

Comme vous l’aurez deviné, cette ligne indique à periodic d’écrire le compte rendu de sa tâche de maintenance quotidienne dans le fichier /var/log/daily.out.
Vous remarquerez qu’une ligne équivalente existe pour les deux autres sections.

Pour faire en sorte que le compte rendu soit envoyé par email plutôt qu’écrit dans un fichier, il suffit de remplacer le nom du fichier de cette ligne par le nom de compte du destinataire, root, dans notre cas.
Vous pourriez effectuer la modification uniquement dans ce fichier, mais periodic vous offre la possibilité d’utiliser un fichier où les valeurs indiquées se substituent aux valeurs du fichier /etc/defaults/periodic.conf.
Cette astuce vous permet d’éviter de modifier le fichier par défaut.

Pour cela, vous devez créer un nouveau fichier /etc/periodic.conf et y ajouter les lignes d’options que vous souhaitez, et periodic saura qu’il devra suivre cette configuration spécifique plutôt que celle de son fichier de configuration par défaut.

Vous devrez encore utiliser sudo pour pico puisque /etc est uniquement modifiable par root :

sudo pico /etc/periodic.conf

Puisque ce fichier n’existe pas encore, cette commande le créera et l’ouvrira pour l’édition.
Tapez simplement ces lignes pour indiquer à periodic d’envoyer la sortie des ces tâches daily, weelkly et monthly à root :

daily_output=root
weekly_output=root
monthly_output=root

Sauvegardez ces fichiers et fermez pico comme d’habitude et vous n’êtes plus qu’à un pas de la fin.
La dernière étape, et de recevoir les rapports dans votre boîte aux lettres plutôt que celle de root.
Vous effectuerez cela en utilisant le fichier .forward

Un fichier .forward est un simple fichier texte
qui contient juste le nom du compte vers lequel le courrier doit être
renvoyé (dans ce cas, votre nom de compte). Une fois le fichier .forward
mis en place dans le répertoire local de l’adresse d’origine (dans ce
cas, root), le courrier est renvoyé comme on
s’y attend.

Par défaut, dans Mac OS X, le répertoire local de root contient déjà un fichier .forward, mais celui-ci ne renvoie pas le courrier à qui que ce soit, mais dans le vide.
C’est le cas parce qu’au lieu de contenir un nom de compte utilisateur, le fichier .forward de root contient le fichier /dev/null, qui est la version Unix d’un trou noir.
Les flots de données redirigés vers /dev/null, courriers inclus, disparaissent.
Comme les concepteurs de OS X ont supposé que la plupart des gens n’utiliseront pas l’email de root, ils ont utilisé cette méthode pour s’assurer que le courrier ne s’accumule pas sur aucun compte, au risque de remplir le disque dur.

Il nous suffit d’éditer le fichier .forward de root.
Vous avez probablement remarqué qu’il n’existe pas de répertoire root dans /Users — alors où est le répertoire local de root ?
La façon la plus simple de trouver le répertoire local de quelqu’un est d’utiliser la commande finger, qui fournie quelques informations simples concernant le compte spécifié.
Pour root nous obtenons :

[haru:~] chris% finger root
Login: root                     Name: System Administrator
Directory: /var/root            Shell: /bin/tcsh
Last login Fri Oct 11 19:46 (PDT) on console
No Plan.
[haru:~] chris%

A côté de Directory vous pouvez voir que le répertoire de root est /var/root.

Autrement, vous pouvez toujours spécifier le répertoire local d’un utilisateur en utilisant le raccourci ~ suivi du nom du compte.
Et donc, si vous voulez spécifier le répertoire local de root, vous pouvez utiliser ~root.

[haru:~] chris% sudo ls /var/root
.CFUserTextEncoding .forward     .nsmbrc      Library

Rappelons quelques points à propos de cette commande :

• Contrairement aux autres répertoires dans /Users, ~root ne peut être listé que par root.
  Il est donc nécessaire d’utiliser sudo.
• Vous pouvez voir plusieurs éléments commençant par .. Ce point initial est la façon dont Unix spécifie que ces fichiers sont invisibles au shell (et au Finder par la même occasion).
  Vous pouvez cependant les voir parce que vous utilisez ls en tant que root, et ls affiche tout à root par défaut.
  Si vous utilisez ls en tant que simple utilisateur, vous devez utiliser l’option -a pour afficher ces fichiers cachés.
  Pour exemple, comparer le résultat de ces deux commandes : ls -a ~ et ls ~ (elles affichent le contenu de votre répertoire local, avec et sans les fichiers cachés).

Dans tous les cas, vous devriez maintenant pouvoir voir ~root/.forward, alors éditez le avec pico, en utilisant sudo puisque c’est un fichier appartenant à root.

sudo pico /var/root/.forward

Vous devriez voir quelque chose comme :

Cette simple ligne est tout le contenu de /var/root/.forward.
Pour la modifier, supprimez cette ligne en pressant Control+K.
Ensuite, tapez votre nom de compte (c’est le nom qui se trouve juste avant le “%” de l’invite ; “chris” dans mon cas) :

Sauvegardez le fichier et fermez pico comme d’habitude, et vous en avez terminé avec le fichier .forward.

Maintenant que tout est en place, vous pouvez effectuer un test.
Envoyez un nouveau message à root :

[haru:~] chris% mail root
Subject: Test 2
This is only a test, again.
.
EOT
[haru:~] chris%

Vérifiez votre courrier, et vous devriez voir un nouveau message, renvoyé par root :

haru:~] chris% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/mail/chris": 1 message 1 new
>N  1 chris          Wed Jan 22 08:56  13/406   "Test 2"
&
Message 1:
From root  Wed Jan 22 08:56:20 2003
Date: Wed, 22 Jan 2003 08:56:20 -0800 (PST)
From: Chris Stone <chris>
To: root
Subject: Test 2

This is only a test, again.

& q
Saved 1 message in mbox
[haru:~] chris%

Voici quelques autres petits trucs pour utiliser mail :

• Si vous avez plusieurs messages listés, tapez simplement le numéro du message que vous souhaitez lire pour qu’il s’affiche.
• Une fois que le message est affiché, il n’apparaît plus dans la liste des nouveaux courriers, car il est sauvegardé dans le fichier ~/mbox.
  Vous pouvez supprimer ce fichier sans soucis, si vous n’avez plus besoin des messages.
  Si vous voulez afficher un message sauvegardé, utilisez mail avec l’option -f, qui affichera la liste des messages sauvegardés.

Pour un test complet, exécutez la tâche de maintenance quotidienne par la commande :

sudo periodic daily

Une fois que l’invite est revenue, la tâche est terminée, et vous pouvez vérifier votre courrier une fois de plus :

[haru:~] chris% sudo periodic daily
Password:
[haru:~] chris% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/mail/chris": 1 message 1 new
>N  1 chris       Wed Jan 22 09:08  59/2244  "Haru.local"

Si vous regardez le message, le début devrait ressembler à quelque chose comme :

Message 1:
From root  Wed Jan 22 09:08:54 2003
Date: Wed, 22 Jan 2003 09:08:54 -0800 (PST)
From: Chris Stone <chris>
To: root
Subject: Haru.local daily run output

Subject: Haru.local daily run output

Removing scratch and junk files:
rm: ./Mount01: is a directory
rm: ./Mount02: is a directory
rm: ./Mount03: is a directory
rm: ./Mount04: is a directory
rm: ./vi.recover: is a directory
rm: ./zBooterMnt: is a directory

Backing up NetInfo data

Checking subsystem status:

disks:
Filesystem   1K-blocks     Used    Avail Capacity  Mounted on
/dev/disk0s9  19532400 13471036  5866040    69%    /
fdesc                1        1        0   100%    /dev

Maintenant que ces rapports vont régulièrement vous parvenir, vous souhaitez certainement savoir ce qu’ils signifient.
En troisième partie, vous en apprendrez plus à propos des scripts eux-même, et à interpréter les rapports qu’ils génèrent.
Jusque-là, vérifiez que vous recevez bien les rapports comme prévu.

Textes originaux en anglais sur O’Reilly :
target=”_blank”>Learning the Terminal in Jaguar, Part 2 par Chris Stone

opoppon Le Terminal de Mac OS X Mac OS X, shell, terminal