Le Terminal de Mac OS X : Partie 3
Maintenant que vous avez paramétré les maintenances régulières de cron à des heures plus raisonnables et que vous revecez par courrier électronique chaque rapport de maintenance, vous aimeriez probablement découvrir quelles maintenances effectue réellement cron et la signification de ces rapports.
Aujourd’hui nous allons explorer ces deux sujets puis nous finirons ce tutoriel avec une paire de “variations sur le thème” - des procédures complémentaires pour rendre ce processus plus facile encore (avec leurs propres compromis et avertissements, malgré tout).
Le script Quotidien
Pour commencer, jetons de nouveau un oeil sur le système crontab, plus particulièrement la commande relative à l’action quotidienne :
sh /etc/daily 2>&1 | tee /var/log/daily.out | mail -s "`hostname` daily output" root
Comme vous devez vous en souvenir, cron emploie le shell Bourne (sh) pour exécuter le script situé dans /etc/daily. La réelle consistance de cette tâche, présente dans ce fichier, est assez longue et complexe et exigerait plusieurs articles pour en faire complètement le tour. Cependant, le script contient des commentaires décrivant chaque action générale, ce qui permet rapidement d’avoir une vue globale de ce qui y est effectué.
Le fichier /etc/daily est trop long pour l’afficher avec la commande cat. En remplacement, vous aurez besoin d’une application qui puisse afficher un bloc de données par écran, ou “une page” à la fois. De telles applications sont appelées des pagers et un des pagers le plus utilisé est : plus.
Comme vous l’avez fait avec cat, entrez “plus” et le chemin d’accès du fichier pour en voir la première page. Pour voir le script quotidien, entrez ceci :
more /etc/daily
Pour vous déplacer à la page suivante, appuyez sur la barre d’espace. (Pour revenir, appuyez sur B). En bas de l’écran more, vous verrez le nom du fichier en cours d’affichage et un indicateur de pourcentage de contenu affiché. Pour sortir de more, tapez Q.
Alors que vous lisez attentivement le script, gardez toujours à l’esprit que les lignes commençant par le caractère # sont ignorées quand le shell parcours le script. Normalement, de telles lignes contiennent des commentaires descriptifs du script, mais elles peuvent aussi être des commande réelles qui pour des raisons diverses sont désactivées, et “décommentées” par la suite.
L’intérieur de la fenêtre more avec le pourcentage de contenu parcouru.
De même, les lignes de commande commençant par echo fournissent des informations qui seront transférées dans le rapport. Par exemple, ces deux premières lignes introduisent le rapport quotidien par une ligne blanche et une ligne de texte :
echo ""
echo "Removing scratch and junk files:"
Encore une fois, je ne peux pas détailler entièrement ce script dans cet article, mais ce qui suit est le plus intéressant à savoir. Les parties du script que nous n’aborderons pas sont surtout liés à des processus qui ne sont pas applicables à un système OS X “standard”.
La première section du script supprime les fichiers “brouillons” et “mis au rebut” de votre système. Plus particulièrement, certains de ces éléments sont :
- Les fichiers existants dans /tmp qui n’ont pas été accédés ou modifiés dans les trois derniers jours. Le répertoire /tmp contient, entre autres choses, le répertoire Temporary Items sollicité par beaucoup d’applications GUI, il est donc souvent sur le point de déborder.
- Les fichiers existant dans /var/tmp qui n’ont pas été accédés depuis au moins une semaine, ou modifiés dans les trois derniers jours. Quelques processus Unix laissent des rebuts ici aussi.
Le script quotidien effectue aussi une des tâches les plus importantes et communes à chacun des scripts : le back-up de votre base de données NetInfo. Si votre base de données NetInfo a un jour besoin d’être restaurée, vous pourrez facilement le faire en utilisant NetInfo Manager (dans Applications -> Utilities) et la base de données sauvegardée, appelée local.nibak.
Le titre de la section suivante du script est, comme vous pouvez le voir dans le rapport de cron, “Vérification du statut du sous-système.”
Vérification du statut du sous-système :
disks: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/disk0s5 40016844 33274772 6742072 83% / fdesc 1 1 0 100% /dev /dev/disk2s1s2 354552 354552 0 100% /Volumes/Q3TA
Ces informations sont le résultat de la commande df -k-l dans le script quotidien. Elles indiquent l’espace employé et libre sur tous les disques locaux. Cet exemple montre un disque système de 40 gigaoctets (qui sera toujours montré comme “monté sur” /, ou “root“) avec environ 6.7 gigaoctets d’espace libre.
Vous pouvez ignorer la ligne fdesc, qui ne se réfère à aucun disque réel, mais à un des composants de la plomberie du système de fichiers.
Les autres volumes locaux que vous avez montés seront aussi montrés dans cette liste. Cet exemple montre un disque (en fait, un CD-ROM) monté sur /Volumes/Q3TA. Cet attribut, connu comme étant “le point de montage” du disque vous indique le chemin à prendre pour atteindre ce disque via le Command Line Interpretor. Par exemple, pour jeter un coup d’oeil à l’intérieur du CD Q3TA vous pourriez entrer ls/Volumes/Q3TA.
Vous trouverez tous les disques locaux et la plupart des volumes de réseau montés dans /Volumes.
La commande suivante vérifie tout simplement la file d’attente de sendmail et le nombre de messages non délivrables qui y résident. Si le rapport montre que ce répertoire n’est pas vide (et la procédure de ce tutoriel doit être votre seule utilisation de sendmail), il est donc probable que vous ayez eu quelques problèmes avec sendmail.
Le script quotidien lance alors la commande netstat -i qui affiche les statistiques réseau dans le rapport, dont quelques lignes peuvent ressembler à cela :
network: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 16384 <Link> 2015 0 2015 0 0 lo0 16384 127 localhost 2015 0 2015 0 0 en1 1500 <Link> 00.30.65.xx.xx.xx 0 0 0 0 0 en0 1500 <Link> 00.30.65.xx.xx.xx 646365 0 670550 0 0 en0 1500 192.168 192.168.0.40 646365 0 670550 0 0
La commande netstat -i liste vos interfaces de réseau ligne par ligne, et indique les statistiques liées au trafic de chaque interface (depuis son activation) dans les colonnes. Cet exemple ne montre en réalité que deux interfaces matériel : en1 est une carte Airport inactive et en0 est le port Ethernet actif.
Vous verrez aussi quelques lignes relatives aux interfaces IP, y compris l’interface “local loop” (lo0). A ce point, vous vous concentrerez uniquement sur les lignes “<link>” dans la colonne Network. Les autres colonnes intéressantes sont les colonnes de comptabilisation des paquets actuels :
Ipkts -- Incoming packets Ierrs -- Incoming packet errors Opkts -- Outgoing packets Oerrs -- Outgoing packet errors Coll -- Packet collisions
Ce par quoi vous devez vous sentir concernés ce sont les données non-nulles indiquées dans les colonnes “collision” et “erreur”. Je n’entrerai pas ici dans le diagnistic d’une panne de votre réseau, mais cette page pourrait être un bon endroit pour démarrer votre enquête si cela devait survenir : http://www.princeton.edu/~Eunix/Solaris/troubleshoot/netstat.html.
La tâche importante suivante du script quotidien est la “rotation” du fichier log système. Ce fichier log, system.log, enregistre le statut et les messages d’erreur de tous les nombreux processus qui constituent l’OS.
Si aucune sauvegarde du fichier system.log n’a été effectuée, le script fait la première sauvegarde, la compresse en employant gzip et la numérote 0. Cela résulte en un fichier appelé system.log.0.gz. En “faisant tourner” ce fichier log les jours suivants, le script rebaptisera d’abord le system.log.0.gz en system.log.1.gz et créera ensuite un nouveau system.log.0.gz.
Chaque jour, le script crée un nouveau fichier system.log.0.gz après incrémentation par 1 des autres noms de fichiers sauvegardés. Par contre, une fois atteint le nom de fichier system.log.7.gz, aucun autre fichier de sauvegarde n’est crée. Au lieu de cela, le prochain fichier de system.log.6.gz (rebaptisé en system.log.7.gz) écrasera le fichier system.log.7.gz précédent.
Cette procédure s’assure enfin que vous aurez toujours plus d’une semaine de sauvegarde de fichiers log auxquels vous pourrez vous référer en cas de problèmes, mais pas au point de gaspiller inutilement de l’espace disque et probablement trop pour y trouver facilement quelque chose.
Ensuite, le script “nettoie” les fichiers log de votre serveur Web en supprimant tous les fichiers qui ont été archivés depuis plus d’une semaine.
Le script Hebdomadaire
Le script hebdomadaire exécute trois tâches importantes, aucun ne fournit d’informations dans le rapport à part le fait que la commande a bien été exécutée.
Placer
Un des utilitaires UNIX le plus utile du CLI est locate, un localisateur de fichier rapide comme l’éclair. Locate agit en fouillant une base de données, sur votre système, de noms de fichier créés en indexant chaque chemin d’accès. Au lieu de balayer vos disques pour y trouver un fichier, locate interroge juste sa base de données pré indexée et vous donne le résultat presque immédiatement.
Cependant, les résultats de locate sont aussi précis que ne l’est sa base de données. Les fichiers créés après que la base de données ait été construite ne seront pas “localisés”. Locate n’est pas l’outil idéla pour toutes les recherches, mais avec une reconstruction hébdomadaire de sa base de données, ce sera génial pour retrouver ce fichier perdu depuis longtemps que vous savez caché quelque part sur votre disque. La première tâche du script hebdomadaire, alors, sera de reconstruire la base de données de locate.
Si vous êtes curieux d’essayer locate par vous même, jetez un oeil au petit tutoriel inclus dans cet article.
Le script hebdomadaire met à jour une autre base de données importante utilisée par la commande whatis. Whatis est un petit pense-bête qui vous montre rapidement la fonction d’une commande donnée, comme cela :
[localhost:~] chris% whatis netstat netstat(1) - show network status
En fait whatis affiche la première ligne de la page “man” de la commande. Si vous n’êtes pas déjà familiers avec les pages man, vous vous devez de l’être. Celles-ci comprennent l’ensemble de la documentation en ligne d’Unix incluse dans Mac OS X. Regardez ici pour un bon tutoriel sur l’utilisation de man.
Le script hebdomadaire crée alors une base de données whatis de toutes les pages man qu’il trouve, permettant à whatis de délivrer une réponse très rapide.
Enfin, le script hebdomadaire effectue l’archivage de plusieurs autres fichiers log, y compris ceux de ftp et de netinfo.
Le script Mensuel
Il y a en réalité très peu de choses dans le script mensuel, mais ce qu’il fournit peut être assez intéressant, si vous aimez savoir où va tout votre temps machine. La première tâche du script mensuel est de lancer l’utilitaire de “connect time accounting” : ac. (”connect” au sens de “logué”).
Lancé à partir du script mensuel, ac annonce le temps cumulatif, en heures, de connexion de chaque compte d’utilisateur depuis la dernière fois que le script a été lancé, ainsi que le total de tous les utilisateurs :
Doing login accounting:
total 714.22
chris 548.76
miho 101.77
andy 54.39
jonny 9.18
test1 0.06
ftp 0.06
Ac calcule ces totaux en lisant le fichier log courant wtmp, qui enregistre chaque établissement de connexion et et chaque déconnexion. Vous pouvez obtenir cette liste n’importe quand avec la commande last :
[localhost:/var/log] chris% last chris ttyp2 Thu Feb 21 16:18 still logged in chris ttyp1 Thu Feb 21 16:16 still logged in chris console localhost Thu Feb 21 16:02 still logged in reboot ~ Thu Feb 21 16:01
Comment ac sait qu’il doit reprendre la comptabilisation à chaque mois ? Et bien, juste après que ac délivre ses découvertes, le script mensuel archive le fichier log wtmp, créant un nouveau fichier wtmp vide prêt à enregistrer les nouvelles connexions. La prochaine fois que le script mensuel sera lancé, alors, ac fera ses calculs à partir de ce nouveau fichier.
Maintenant que vous avez une bonne idée de ce que font les trois tâches principales de cron et de ce qu’il faut chercher dans les rapports, je vais revenir une dernière fois à la procédure que nous avons suivie et vous faire découvrir une paire de “variations sur le thème”.
Utilisation d’autres Clients de Courrier
Bien sûr, tout le monde n’emploie pas l’application Mail.app comme client d’email et être obligé de lancer cette application uniquement pour lire les rapports de cron n’est pas très commode. Ce n’est pas une situation entièrement désespérée, étant donné ces deux alternatives :
D’abord, employez l’utilitaire à ligne de commande mail. Depuis le début, votre fenêtre Terminal est probablement toujours ouverte de toute façon :-), vous n’avez donc qu’à taper mail pour lire n’importe quels rapports entrants. Et comme vous auriez pu le remarquer, vous êtes alertés de tout nouveau courrier à destination de votre compte Unix à chaque fois que vous ouvrez une nouvelle fenêtre Terminale. Voici un tutoriel sur l’ utilisation de mail : http://wss.berkeley.edu/unix/faq/mail.html.
Ensuite, ajoutez votre adresse électronique régulière au fichier ~root/.forward. Si vous avez la chance d’avoir un compte email avec lequel cela fonctionne, c’est votre meilleure solution. Les raisons qui pourraient être à l’origine de disfonctionnements sont compliquées, mais la manière de tester facilement la validité de votre adresse email est d’employer l’utilitaire CLI mail pour vous envoyer un email :
[localhost:~] chris% mail chris@oreilly.com Subject: Test message Hé, ça a marché ! . EOT [localhost:~] chris%
Si vous obtenez le message, vous pouvez donc ajouter l’adresse au fichier .forward, ou, si vous ne vérifierez jamais votre courrier Unix, remplacerez celle qui y est paramétrée en vous servant de pico. Voici la commande pour l’éditer rapidement :
[localhost:~] chris% sudo pico ~root/.forward
Pour ajouter une adresse, placez une virgule et un espace après celle déjà renseignée et entrez la nouvelle :
Chris, chris@oreilly.com
Le courrier qui sera expédié à votre compte mail régulier pourra alors être lu dans n’importe quel client email. Avec Eudora ou Entourage, par exemple, vous pourriez aussi créer une règle pour acheminer les rapports de cron dans leur propre dossier.
Elimination des erreurs d’autorisations de sendmail
Comme vous devez vous en souvenir, nous avons eu besoin de changer les autorisations du répertoire racine pour que sendmail fonctionne. Bien que dans la plupart des cas cela marche très bien, cette manière de contourner le problème apporte son lot de compromis. Par exemple, les mises à jour Apple auront toujours pour effet de remettre ces autorisations à leur état initial, ce qui vous obligera de nouveau à vous servir de chmod pour que sendmail fonctionne.
Ensuite et ce qui est plus important, il y a une raison importante qui justifie qu’Apple ne veuille pas que le répertoire racine ne soit modifiable par quiconque en dehors du groupe root. Beaucoup d’applications d’installation Classic (et même quelques natives) sont programmées pour placer des articles dans le répertoire racine et si vous ne donnez pas à ces applications des privilèges d’administrateur, elles se planteront. La manière qu’a trouvé Apple de contourner cette possibilité a été de maintenir l’autorisation d’écriture au groupe de ce répertoire.
Bien sûr, cela cause des problèmes pour sendmail, qui exige ces autorisations pour des raisons de sécurité. A ce point, vous pourriez vous sentir coincés entre le marteau et l’enclume. Mais ne serait ce pas génial si vous pouviez dire à sendmail (comme Ben Franklin), “Hé, je veux bien un peu céder sur le plan sécuritaire si vous me donnez la liberté de gérer mes autorisations !“.
En fait, sendmail vous permet de mettre cette option en ajoutant une simple ligne à son fichier de configuration. Extrait de la documentation sendmail :
“Vous devrez ajuster votre environnement pour faire en sorte que sendmail fonctionne. Si vous constatez que certaines des sécurités dans sendmail sont trop restrictives pour votre environnement, elles peuvent être désactivées en mettant l’option DontBlameSendmail. Cette option est convenablement intitulée dans le sens où sendmail ne peut être blâmé de problèmes résultant de permissions risquées sur des répertoires et des fichiers.”
Tant que vous employez sendmail comme décrit dans le tutoriel et que vous êtes l’utilisateur principal de la machine, le risque de sécurité est négigeable si vous utilisé cette option. Cependant, si vous n’êtes pas capables de contrôler les accès à votre machine que ce soit physiquement ou à distance et que votre système est corrompu, ne me blâmez pas non plus s’il vous plaît 
Ainsi si vous êtes prêts à le faire, le fichier que vous devez éditer est /etc/mail/sendmail.cf. Faites en d’abord une sauvegarde. Puisque le répertoire /etc/mail n’est seulement modiable que par root, vous aurez besoin de sudo :
sudo cp -p /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak
Notez l’utilisation de l’option -p dans cette ligne de commande, qui véhicule les autorisations originelles lors de la copie du fichier. Cela rendra les choses un peu plus faciles, si vous deviez rapidement rétablir le fichier.
Vous pouvez alors éditer ce fichier en employant pico, comme vous l’avez déjà fait avec d’autres. Sachant que sendmail.cf n’est modiable que par root, vous devrez employer sudo ici aussi.
sudo pico /etc/mail/sendmail.cf
Ce fichier contient plus de 1 200 lignes et pourrait donc être intimidant, mais puisque vous n’allez ajouter qu’une simple ligne en début de fichier et en sortir très vite, rien ne doit vous inquiéter.
La ligne que vous cherchez est en commentaire et elle contient “DonBlameSendmail” à environ 70 lignes à partir du début du fichier. La façon la plus rapide de la trouver dans pico est d’appuyer sur Control + W, d’entrer “DontBlame” et d’appuyer sur Retour. Vous devriez alors voir ces lignes :
# level 9 config file format
V9/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
Ensuite, ajoutez une ligne après celle que avez trouvée et saisissez (ou copiez-collez) cette ligne :
O DontBlameSendmail=GroupWritableDirPathSafe
Quand vous aurez fini, les lignes doivent ressembler à cela :
# 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, ctrl + O pour sauvegarder le fichier, Retour pour confirmer le nom et ctrl + X pour quitter pico. Vous pouvez maintenant remettre les autorisations du répertoire racine à leur valeurs d’usine avec cette commande :
[localhost:/etc/mail] chris% sudo chmod g+w /
Si tout va bien, sendmail enverra son courrier la prochaine fois qu’il sera sollicité, même avec un répertoire root uniquement modifiable par les membres du groupe root.
Si vous avez toujours des problèmes avec quoique ce soit, n’hésitez pas à consulter les sections “TalkBack” (en anglais) de chaque tutoriel original où des lecteurs et moi même avons couvert la plupart des problèmes classiques et avons apporté quelques corrections.
Enfin, si vous voullez en apprendre plus sur cron, voici un autre tutoriel pour vous.
Maintenant que vous êtes sur les genoux après tout ce que vous avez appris sur le Terminal et sur UNIX, vous voilà devant un océan de connaissances à explorer. J’espère que cet exercice vous a donné suffisamment de confiance pour plonger dedans.
Je projette aussi de mettre en ligne un peu plus d’articles qui me sont propres dans un proche avenir, n’hésitez donc pas à formuler des demandes dans la section “TalkBack“. A bientôt !
Remerciements spéciaux à Fred Coffman pour son aide dans cet article.
Suite à la mise à jour en 10.1.5
Comme tout ceux qui ont appliqué la mise à jour 10.1.5 de Mac OS X, vous avez du découvrir que sendmail ne fonctionne plus comme décrit dans cet article. La version 10.1.5 met à jour sendmail (de la version 8.11 à la version 8.12.2) et accroît considérablement la sécurité des processus.
Bref, vous devez donc produire un nouveau fichier sendmail.cf en partant de zéro et en se servant de m4 “l’utilitaire de macro-langage”. Vous devrez aussi changer quelques permissions, tout comme configurer votre système pour lancer le démon sendmail au démarrage. (Ce n’était pas nécessaire pour l’envoi du courrier local dans les versions système 10.1.4 et inférieures, mais apparemment ça l’est maintenant).
Si vous employez principalement sendmail pour recevoir localement les rapports de Cron, comme décrit dans le tutoriel initial, les étapes suivantes vous permettront de les obtenir de nouveau. Si vous employez sendmail pour faire plus que cela, cette procédure devrait toujours fonctionner, mais je ne peux pas le garantir.
Aussi, si vous avez fait d’autres modifications antérieures dans votre sendmail.cf, vous devrez de nouveau les effectuer dans celui que vous allez produire ici. Je vous montrerai comment ajouter la ligne DontBlameSendmail de nouveau.
- Vous trouverez quelques instructions, que je paraphrase ici, dans /etc/mail/README :Dirigez vous vers /usr/share/sendmail/conf/cf :
cd /usr/share/sendmail/conf/cf
Copiez le fichier de configuration par défaut dans le fichier yourdomain.mc :
sudo cp generic-darwin.mc yourdomain.mc
(Vous pouvez employer le littéral “yourdomain” si vous n’avez pas de nom de domaine pour votre machine. Si vous avez un nom de domaine, employez-le à la place).
Si vous voulez employer l’option DontBlameSendmail comme décrit dans le tutoriel initial, vous pouvez l’ajouter au fichier mc ici :
sudo pico yourdomain.mc
Et ajoutez cette ligne à la fin du fichier :
define (`confDONT_BLAME_SENDMAIL', `GroupWritableDirPathSafe') dnl
Régénérez votre fichier sendmail.cf à partir du fichier m4 que vous venez juste d’éditer :
m4 ../m4/cf.m4 yourdomain.mc > /tmp/sendmail.cf
Faites un back-up de votre vieux sendmail.cf :
sudo cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.orig
Mettez votre nouveau sendmail.cf à la place :
sudo cp /tmp/sendmail.cf /etc/mail/
La nouvelle version de sendmail est compilée pour rechercher dans NetInfo le pointeur de son fichier config, vous devriez donc normalement ajouter cette donnée dans la base de NetInfo. Pour s’assurer que sendmail ne cherchera pas son fichier config dans la base de NetInfo, exécutez les commandes suivantes :
sudo niutil -create . /locations/sendmail sudo niutil -createprop . /locations/sendmail sendmail.cf /etc/mail/sendmail.cf
Cela indiquera à sendmail (au moment où il va scruter NetInfo) de ne pas chercher dans NetInfo le pointeur de son fichier config, mais de prendre en compte /etc/mail/sendmail.cf.
- Corrigez le groupe du répertoire de file d’attente du client sendmail :
sudo chgrp smmsp /var/spool/clientmqueue
- Si vous n’employez pas l’option DontBlameSendmail, vous devrez de nouveau désactiver les autorisations d’écriture de groupe pour le répertoire root, sachant que la mise à jour système les a ré-activées :
sudo chmod g-w /
- Pour faire en sorte que sendmail soit lancé au démarrage du système, vous devrez modifier deux fichiers. Ouvrez d’abord /etc/hostconfig :
sudo pico /etc/hostconfig
Trouvez cette ligne :
MAILSERVER =-NO-
Et remplacer NO par YES :
MAILSERVER =-YES-
Sauvegardez ce fichier et ouvrez ensuite /System/Library/StartupItems/Sendmail/Sendmail :
sudo pico /System/Library/StartupItems/Sendmail/Sendmail
Trouvez cette ligne près de la fin du fichier :
/usr/sbin/sendmail -bd -q1h
Et ajoutez cette ligne juste après :
/usr/sbin/sendmail -C /etc/mail/submit.cf -q1h
Sauvegardez ce fichier et redémarrez votre machine pour permettre au script de démarrage de tourner. Vous devez constater que sendmail fonctionne de nouveau comme il le faisait dans la 10.1.4. Il se peut que ces étapes soient simplifiées par la suite et je vous en tiendrai informé si c’est le cas. Pour le moment, cependant, cela vous permettra de rétablir la situation.
Textes originaux sur O’Reilly : Update to Mac OS X Terminal, Part 3
Chargement
Commentaires récents