Le Terminal de Jaguar - Partie 3
Maintenant que vous avez les jobs de maintenance cron fonctionnant à des heures plus appropriées et qu’ils vous envoient par email leurs rapports, vous voudriez sûrement savoir ce que ces jobs font, et ce que leurs rapports peuvent vous apprendre.
Le Script Quotidien
Pour commencer, regardons le fichier crontab système, plus particulièrement la commande pour le job quotidien :
15 3 * * * root periodic dailyComme vous vous en souvenez peut-être, cron utilise l’utilitaire periodic pour lancer les scripts se trouvant dans le répertoire /etc/periodic/daily/. Les éléments importants pour ce job cron se trouvent dans les fichiers 100.clean-logs et 500.daily. Ils sont tous les deux assez complexes et nécessiteraient qu’on leur dédie plusieurs articles afin de pouvoir en donner une explication claire. Cependant, les scripts contiennent des commentaires décrivant chaque tâche générale, et donc en prendre connaissance peut-être très informatif.
Vous vous souvenez peut-être aussi que les nombres dans les noms des fichiers indiquent l’ordre dans lequel periodic les exécutera. Les plus petits nombres en premier, donc nous regarderons en premier le script 100.clean-logs. Pour l’afficher, utiliser more et appuyer sur la touche Entrée :
more /etc/periodic/daily/100.clean-logsPendant que vous regarder ce script, rappelez-vous que les lignes commençant par le caractère # sont ignorées lorsque le shell exécute le script. Ces lignes représentent en général des commentaires concernant le script, mais peuvent également être des lignes de commandes qui pour une raison ou une autre sont désactivées ou “commentées”.
De plus, les lignes commençant par echo, écrivent les lignes que l’on retrouve dans les rapports. Par exemple, ces deux lignes retrouvées dans 100.clean-logs commenceront le rapport quotidien par une ligne vide, et la ligne de texte entre quotes :
echo ""
echo "Removing old log files:" Voici à quoi ressemble le début du fichier :
Comme vous l’avez probablement deviné d’après le nom du script, sa fonction est de supprimer les vieux logs systèmes. En fait, il s’agit d’un script BSD standard qui lit ses informations de configuration depuis le fichier de configuration principal de periodic, /etc/defaults/periodic.conf, qui indique à ce script quel répertoire nettoyer, et combien de temps les fichiers peuvent rester en place sans avoir été modifiés avant qu’ils ne soient supprimés.
Dans le cas de Mac OS X, le répertoire dont il s’occupera est /Library/Logs/CrashReporter, et la durée pendant laquelle les fichiers peuvent rester là avant que le script ne les supprime est de 60 jours. Vous pouvez voir vous-même ces paramètres dans /etc/defaults/periodic.conf. Pour afficher par more un fichier depuis une chaine de caractères spécifique, utiliser son option +/chaineRecherchée.
Par exemple, pour voir la section de /etc/defaults/periodic.conf qui commence par la chaine de caractère 100.clean-logs, utilisez cette commande :
# 100.clean-logs
daily_clean_logs_enable="YES"
# Delete stuff daily
daily_clean_logs_dirs="/Library/Logs/CrashReporter"
# Delete under here
daily_clean_logs_days="60"
# If not accessed for
daily_clean_logs_ignore=""
# Don't delete these
daily_clean_logs_verbose="NO"
# Mention files deleted
CrashReporter est un processus démon qui tourne en tâche de fond si vous avez activé “crash reporting” depuis les préférences de l’application Console. (Vous trouverez la Console avec le Terminal dans /Applications/Utilitaires.). CrashReporter est à l’écoute d’applications sur le point de crasher et enregistre leurs derniers instants, des données de déboggage compliquées, dans des fichiers localisés dans /Library/Logs/CrashReporter. Lors de son premier crash, une application se voit créer son propre fichier de log dans ce répertoire, nommé nomApplication.crash.log. Tout crash ultérieur de cette application sera loggé dans ce même fichier.
Si vous utilisez souvent une application qui plante fréquemment, il se peut que le répertoire /Library/logs/CrashReporter accumule de large fichiers. Le script 100.clean-logs de periodic, regardera dans ce répertoire chaque fois qu’il est exécuté et supprimera tout fichier qui n’a pas été modifié depuis au moins 60 jours, puisque ces fichiers ont peu d’intérêt.
Le prochain script exécuté de façon quotidienne est 500.daily. Ce script est beaucoup plus long ; encore une fois, je ne peux pas le détailler ici, mais ce qui suit en sont les sections les plus pertinentes. Les parties non traitées ne sont pas applicables à une version classique de Mac OS X.
La première section du script supprime de votre système les fichiers “détritus”. Plus spécifiquement, ces fichiers sont :
- Les fichiers situés dans /tmp qui n’ont pas été accédés ou modifiés depuis au moins trois jours. Le répertoire /tmp contient, entre autres choses, le répertoire Temporary Items utilisé par de nombreuses applications en mode graphique, alors il est souvent plein comme une poubelle.
- Les fichiers situés dans /var/tmp qui n’ont pas été accédés depuis au moins une semaine, ou modifiés depuis au moins trois jours. Certains processus Unix laisse des traces ici aussi.
Le script 500.daily effectue également l’une des tâches les plus importantes de ce script, qui est, la sauvegarde de la base de donnée NetInfo. En fait, la commande en tâche de fond du script ne duplique pas la base de données comme vous pouvez le faire depuis NetInfo Manager (que l’on trouve dans /Applications/Utilitaires), mais sauvegarde les données de façon brute dans un fichier local.nidump situé dans /var/backups.
Récupérer votre base de données à partir de ce fichier demande un peu de travail, mais effectuer la douzaine d’étapes nécessaires vaudraient la peine si aviez vraiment besoin de restaurer vos données NetInfo. Vous trouverez une bonne description de ces étapes (qui ont été testées avec Mac OS X 10.2.4) ici.
L’en-tête de la section suivante de ce script est, comme vous pouvez le voir dans le rapport cron, “Checking subsystem status” (Vérification de l’état du sous-système).
Checking subsystem status:
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 valeurs sont le résultat de la commande df -k -l du script quotidien, qui détaille les espaces occupé et libre de tous les disques locaux. Cet exemple montre un disque de 40 Go (indiqué par / dans la colonne “Mounted on”, ou “root”) avec 6,7 Go d’espace libre.
Vous pouvez ignorer la ligne fdesc, qui ne fait pas référence à un disque réel, mais permet de partitionner le système de fichiers.
Tout autre volume local que vous avez pu monté apparaitra dans la liste. Cette exemple montre un disque (en fait, un CD-ROM) monté sur /Volumes/Q3TA. Cet attribut, “le point de montage” du disque, vous indique le chemin qu’il vous faudra suivre pour atteindre ce disque depuis la ligne de commande. Par exemple, pour lister le contenu du CD Q3TA vous taperiez ls /Volumes/Q3TA.
Vous trouverez tous les disques locaux et la plupart des volumes de réseaux montés depuis /Volumes.
La prochaine commande intéressante vérifie simplement la file d’attente de sendmail pour tout message non délivré. Si le rapport ne montre pas que ce répertoire est vide (et que la procédure de ce tutoriel est votre seule utilisation de sendmail), alors il est probable que vous ayez des problèmes avec sendmail.
Ensuite, le script 500.daily exécute la commande netstat -i, qui écrit les statistiques réseau dans le rapport, dont quelques lignes pourraient ressembler à cela :
network: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 16384 <Link#1> 15528 0 15528 0 0 lo0 16384 localhost ::1 15528 - 15528 - - lo0 16384 fe80:1::1 fe80:1::1 15528 - 15528 - - lo0 16384 127 localhost 15528 - 15528 - - gif0* 1280 <Link#2> 0 0 0 0 0 stf0* 1280 <Link#3> 0 0 0 0 0 en0 1500 <Link#4> 00:03:93:bd:c9:2c 160141 545668 54718 0 0 en0 1500 fe80:4::203 fe80:4::203:93bb: 160141 - 54718 - - en0 1500 172.24 dhcp-172-24-31- 160141 - 54718 - - en0 1500 (16)00:00:00:67:24 160141 545668 54718 0 0 en1 1500 <Link#5> 00:30:bd:09:4b:bd 7723 0 2489 0 0 en1 1500 fe80:5::230 fe55:5::230:65ff: 7723 - 2489 - - en1 1500 172.18 172.18.1.21 7723 - 2489 - - ppp0 1466 <Link#6> 0 0 0 0 0 ppp0 1466 172.24 dhcp-172-24-40- 0 - 0 - -
La commande netstat -i liste les interfaces réseaux en lignes, montrant les statistiques de traffic pour chacune (depuis son activation) dans les colonnes. Cet exemple affiche deux interfaces matériels : en1 est une carte Airport, et en0 est le port Ethernet. L’inteface ppp0 affichée est utilisée par le client VPN PPTP.
Vous verrez d’autres lignes pour les interfaces IP, y compris l’interface “local loop” / “boucle locale” (lo0), et quelques autres liées à IPv6 (stf0 et gif0). Ici, concentrez-vous sur les lignes qui indiquent “<link>” dans la colonne réseau. Les autres colonnes intéressantes sont les colonnes de comptage de paquets :
Ipkts -- Incoming packets / Paquets entrants
Ierrs -- Incoming packet errors / Paquets erreur entrants
Opkts -- Outgoing packets / Paquets sortants
Oerrs -- Outgoing packet errors / Paquets erreur sortants
Coll -- Packet collisions / Collisions de paquets
Ce qui doit vous alerter, bien sûr, ce sont toutes les entrées non nulles dans les colonnes erreur ou collision. Je ne m’aventurerai pas à la résolution de problèmes de réseau ici, mais cette page pourrait être un bon point de départ si quelque chose apparaissait : http://www.princeton.edu/~unix/Solaris/troubleshoot/netstat.html.
La prochaine tâche importante du script 500.daily est la rotation des logs système. Ce fichier log, system.log, enregistre les messages d’état et d’erreur d’un large nombre de processus tournant sur l’OS.
Dans le cas où il n’existe pas encore de sauvegarde de system.log, le script effectue le premier backup, le compresse en utilisant gzip, et lui attribue le numéro 0. Ceci donne la création d’un fichier nommé system.log.0.gz. En effectuant une “rotation” de fichiers log les jours suivants, le script renommera dabord system.log.0.gz en system.log.1.gz, puis créera un nouveau system.log.0.gz.
Chaque jour, le script crée un nouveau fichier system.log.0.gz après avoir incrémenté par un les autres noms de fichiers sauvegardés. Cependant, une fois que system.log.7.gz est créé, il n’y aura pas de neuvième fichier de sauvegarde. Au lieu de cela, à la sauvegarde suivante, le fichier system.log.6.gz (renommé system.log.7.gz) remplacera le fichier system.log.7.gz précédent.
Cette procédure assure que vous aurez plus d’une semaine de logs à laquelle vous référer en cas de problèmes, mais pas trop pour ne pas gaspiller de l’espace disque, et pas trop long pour ne pas être trop difficile à éditer.
Ensuite, le script “nettoie” les fichiers du serveur web en supprimant les fichiers en rotation qui sont présents depuis plus d’une semaine.
Le Script Hebdomadaire
Comme vous avez pu le voir dans le fichier /etc/crontab, cron fait également appel à periodic chaque semaine pour exécuter les scripts du répertoire /periodic/weekly, et le script qu’il trouvera là est nommé 500.weekly.
Le script 500.weekly effectue trois tâches importantes, dont aucune n’écrit dans un fichier de rapport excepté pour indiquer que la tâche a été effectuée (à moins qu’il n’y ait des erreurs).
locate
Une des commandes Unix les plus utiles est l’utilitaire locate, qui permet de retrouver les fichiers ultra rapidement. La magie de locate réside dans une base de données de noms de fichiers créée en indexant tous les chemins d’accès des fichiers de votre système. Au lieu de scanner votre disque pour retrouver un fichier, locate regarde juste dans sa base de données pré-indexée et retourne les résultats presque instantanément.
Cependant, la justesse des résultats de locate dépend de sa base de données. Les fichiers ajoutés après la mise à jour de la base de données ne pourront pas être affichés. locate n’est pas un outil pour toutes les recherches, mais avec une base de données mise à jour toute les semaines, il est très pratique pour retrouver ce fichier oublié qui est enfoui quelque part sur votre disque. La première tâche du script hebdomadaire est donc de mettre à jour la base de données de locate.
Si vous voulez vraiment utiliser locate, jetez un oeil au petit tutoriel inclus dans cet article.
Ce script hebdomadaire met à jour une autre base de données importante utilisée par la commande whatis. whatis vous affiche succintement les fonctionnalités d’une commande donnée, comme ceci :
[localhost:~] chris% whatis netstat
netstat(1) - show network status
Ce qu’affiche whatis en fait, est la première ligne de la “page man” d’une commande. Si vous ne connaissez pas les pages man, il est temps de vous y mettre. Elles représentent une grande collection de documentation Unix en ligne, incluse dans Mac OS X. Regardez ici pour un tutoriel sur l’utilisation de la commande man.
Le script hebdomadaire met à jour la base de données de whatis à partir de toutes les pages man qu’il peut trouver, permettant à whatis de retourner une réponse rapidement.
Enfin, le script hebdomadaire effectue la rotation de plusieurs fichiers log, incluant ceux pour ftp et netinfo.
Le Script Mensuel
Comme vous l’avez également vu dans le fichier /etc/crontab, cron exécute periodic chaque mois pour exécuter tout script trouvé dans le répertoire /periodic/monthly,
Il y a en fait peu de choses dans ce script mensuel, mais ce qu’il effectue peut être assez intéressant, si vous voulez savoir ce que vous faites de votre temps. La première tâche du script mensuel est d’exécuter l’utilitaire ac qui calcule les statistiques de temps de connexion.
Exécuté depuis le script mensuel, ac fera un rapport du temps de connexion cumulé, en heures, pour chaque utilisateur depuis la dernière exécution du script, ainsi que le total pour 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 consultant le fichier de log wtmp, dans lequel sont loggés toutes connexions et déconnexions d’utilisateurs.
Vous pouvez faire afficher ces valeurs n’importe quand en tapant 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 peut savoir qu’il doit recommencer le calcul chaque mois ? Eh bien, juste après que ac ait effectué son rapport, le script mensuel effectue la rotation de logs wtmp, créant un nouveau fichier wtmp vide dans lequel les log peuvent être de nouveau écrits. La prochaine fois que le script est exécuté, ac effectue son calcul sur la base de ce nouveau fichier.
Conclusion
Vous devriez maintenant avoir une bonne idée de ce que font les trois jobs cron, et que rechercher dans les rapports. Si vous avez toutefois des problèmes, regardez dans la section discussion de chaque tutoriel, où les lecteurs et moi-même répondons à la plupart des problèmes et effectuons des corrections.
De plus, si vous voulez en savoir plus par rapport à cron, voici un tutoriel (en anglais) pour vous.
Maintenant que vous avez commencé à faire trempette dans le Terminal et Unix, il vous reste un océan entier à explorer. J’espère que ce tutoriel vous aura donné suffisamment de confiance en vous pour que vous y plongiez. Il existe d’autres articles sur Mac DevCenter que vous devriez maintenant être prêts à aborder, de même que plein d’autres sur internet.
Textes originaux en anglais sur O’Reilly : Learning the Terminal in Jaguar, Part 3 par Chris Stone
Chargement
Commentaires récents