/etc/daily et ses amis

Sur un système NetBSD fraîchement installé, la crontab(5) de root contient trois entrées :

# do daily/weekly/monthly maintenance
15   3   *   *   *   /bin/sh /etc/daily 2>&1 | tee /var/log/daily.out | sendmail -t
30   4   *   *   6   /bin/sh /etc/weekly 2>&1 | tee /var/log/weekly.out | sendmail -t
#30  5   1   *   *   /bin/sh /etc/monthly 2>&1 | tee /var/log/monthly.out | sendmail -t

et l'utilisateur root reçoit donc deux mails toutes les nuits et un dernier mail le samedi matin. Ces trois scripts, suivant la manière dont ils sont configurés et complétés, assurent les tâches de maintenance courante (purger les données de « comptabilité » — accounting, vérifier la queue du MTA, …) et affichent diverses informations renseignant sur l'état du système (utilisation des systèmes de fichiers, recherche de core dumps, …).

À la lecture des pages de manuel de daily.conf(5), weekly.conf(5) et monthly.conf(5), on note que l'on peut ajouter des commandes locales dans des fichiers /etc/{daily,weekly,monthly}.local (et qu'il ne faut pas toucher aux trois fichiers /etc/{daily,weekly,monthly}} pour être tranquille lors des mises à jour).

Dans daily, on peut vérifier les systèmes de fichiers (run_fsck). Pour compléter, on peut suivre les recommandations de Matthias Scheler et vérifier l'état SMART des disques (ou utiliser smartctl(8), cf. sysutils/smartmontools). Idem avec les ensembles de disques RAID (via bioctl(8), wip/tw_cli, … ; raidctl(8) est déjà pris en compte dans daily).

En espérant que l'équipe de http://www.pkgsrc.org soit à l'heure, on peut aussi profiter de daily.local pour automatiser la mise à jour de /usr/pkgsrc (branche stable !) avec ce script ksh(1) :

let Q=$(( $(( $(date '+%m') / 3 )) - 1))
if [ ${Q} -eq 0 ]; then
        Q=3
        Y=$(( $(date '+%Y') - 1))
elif [ ${Q} -lt 0 ]; then
        Q=4
        Y=$(( $(date '+%Y') - 1))
else
        Y=$(date '+%Y')
fi
 
cd /usr/pkgsrc
cvs update -dP -rpkgsrc-${Y}Q${Q}

(ne pas coller tel quel ce morceau de code, daily est un script Bourne, aka sh(1) et non pas ksh(1)).

Il ne reste plus alors qu'à vérifier l'état des paquets installés, par exemple avec pkgtools/pkg_chk :

pkg_chk -qunr

On peut aussi lancer les commandes de sauvegarde et de vérification de ces dernières dans daily.local.

On note aussi que /etc/daily lance /etc/security (le second mail quotidien … daily insecurity output…), lui-même documenté dans security.conf(5) ; ce dernier script exécute /etc/security.local.

Dans /etc/security.local, on peut ajouter l'affichage des tables et/ou des règles du filtre de paquets (ipf(4) ou pf(4)) ou un diff(1). Les utilisateurs de security/py-denyhosts peuvent aussi afficher l'état de /etc/hosts.deny (ou un diff(1)…).

Dans /etc/security.local, on devrait toujours lancer :

audit-packages -d && audit-packages

Le script audit-packages est maintenant fourni avec le système de base ; il s'agit d'un wrapper autour de pkg_admin(8).

Outre security.local, security garde une trace des modifications faites dans les fichiers listés (un par ligne) dans /etc/changelist et dans les deux fichiers /etc/mtree/special et /etc/mtree/special.local (qui seront évoqués dans un prochain billet). Les modifications sont gérées à l'aide de RCS, un vénérable VCS.