Les sections suivantes décrivent les procédures supplémentaires une fois que vous avez terminé la mise à jour des cartes fournies avec l'ensemble par défaut.
Une fois qu'une carte est modifiée, le fichier Makefile utilise la commande yppush pour propager une nouvelle carte sur les serveurs esclaves (à moins que NOPUSH ne soit défini dans le fichier Makefile). Pour cela, il informe le démon ypserv et envoie une demande de transfert de carte. Le démon ypserv résidant sur le serveur esclave démarre alors un processus ypxfr, qui à son tour contacte le démon ypxfrd sur le serveur maître. Certains contrôles de base sont effectués (par exemple, la carte a-t-elle vraiment été modifiée ?). La carte est ensuite transférée. Le processus ypxfr sur le serveur esclave envoie ensuite une réponse au processus yppush pour indiquer la réussite ou l'échec du transfert.
La propriété config/local_only du service svc:/network/rpc/bind doit être définie sur false. Dans le cas contraire, le maître NIS ne peut pas transférer la version mise à jour de la carte maître NIS au serveur esclave NIS au moyen de la commande yppush.
Il arrive que des cartes ne se propagent pas et que vous deviez utiliser ypxfr manuellement pour envoyer les informations relatives aux nouvelles cartes. Vous pouvez choisir d'utiliser ypxfr de deux façons différentes : de manière périodique par le biais du fichier crontab de root ou de manière interactive sur la ligne de commande. Ces approches sont décrites dans les sections suivantes.
Les cartes présentent des taux de modification différents. Par exemple, certaines cartes peuvent ne pas changer pendant des mois, comme protocols.byname parmi les cartes par défaut et auto_master parmi les autres cartes. En revanche, passwd.byname peut changer plusieurs fois par jour. La planification du transfert des cartes à l'aide de la commande crontab permet de définir des heures de propagation spécifiques pour chaque carte.
Pour exécuter régulièrement ypxfr au taux qui convient à la carte, le fichier crontab root sur chaque serveur esclave doit contenir les entrées ypxfr appropriées. ypxfr contacte le serveur maître et transfère la carte si la copie sur le serveur maître est plus récente que la copie locale, et à cette condition uniquement.
Plutôt que de créer des entrées crontab distinctes pour chaque carte, vous préférerez peut-être que la commande crontab root exécute un script shell qui mette régulièrement à jour toutes les cartes. Vous trouverez des exemples de scripts shell de mise à jour des cartes dans le répertoire /usr/lib/netsvc/yp. Ces scripts portent les noms ypxfr_1perday, ypxfr_1perhour et ypxfr_2perday. Vous pouvez modifier ou remplacer ces scripts shell pour vous adapter aux besoins de votre site. L'exemple suivante illustre le script shell ypxfr_1perday par défaut.
Exemple 7-1 Script shell ypxfr_1perday#! /bin/sh # # ypxfr_1perday.sh - Do daily yp map check/updates PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH export PATH # set -xv ypxfr group.byname ypxfr group.bygid ypxfr protocols.byname ypxfr protocols.bynumber ypxfr networks.byname ypxfr networks.byaddr ypxfr services.byname ypxfr ypservers
Ce script shell met à jour les cartes une fois par jour, si la commande crontab root est exécutée tous les jours. Vous pouvez également rédiger des scripts qui mettent à jour les cartes une fois par semaine, par mois, par heure et ainsi de suite. Toutefois, ne perdez pas de vue l'éventuelle baisse de performances qu'implique généralement la propagation des cartes. Pour plus d'informations, reportez-vous à la page de manuel crontab(1).
Exécutez les mêmes scripts shell en tant qu'utilisateur root sur chaque serveur esclave configuré pour le domaine NIS. Modifiez l'heure exacte de l'exécution sur les différents serveurs afin d'éviter tout encombrement du serveur maître.
Si vous souhaitez transférer la carte d'un serveur esclave particulier, ajoutez l'option–h machine de ypxfr dans le script shell. Voici la syntaxe des commandes à insérer dans le script.
# /usr/lib/netsvc/yp/ypxfr –h machine [ –c ] mapname
Où machine est le nom du serveur sur lequel résident les cartes que vous souhaitez transférer et mapname est le nom de la carte demandée. Si vous utilisez l'option –h sans spécifier une machine, ypxfr essaie d'obtenir la carte à partir du serveur maître. Si le démon ypserv ne s'exécute pas localement au moment de l'exécution du processus ypxfr, vous devez utiliser l'indicateur –c pour que ypxfr n'envoie pas une demande claire de carte actuelle au fichier ypserver local.
Vous pouvez utiliser les options –s domain pour transférer les cartes d'un autre domaine vers votre domaine local. Ces cartes doivent être identiques sur l'ensemble des domaines. Par exemple, deux domaines peuvent partager les mêmes cartes services.byname et services.byaddr. Pour plus de contrôle, vous pouvez également exécuter rcp ou rsync pour transférer des fichiers sur l'ensemble des domaines.
La seconde méthode d'appel de ypxfr consiste à l'exécuter en tant que commande. En règle générale, elle ne s'applique qu'à des situations exceptionnelles, par exemple lorsque vous configurez un serveur NIS temporaire pour créer un environnement de test ou lorsque vous tentez d'obtenir rapidement un serveur NIS hors service en accord avec les autres serveurs.
Les tentatives de transfert et les résultats de ypxfr peuvent être consignés dans un fichier journal. Les résultats sont ajoutés au fichier /var/yp/ypxfr.log, s'il existe. Aucune tentative de limiter la taille du fichier journal n'est effectuée. Pour éviter qu'il n'augmente indéfiniment, videz-le régulièrement en tapant la commande suivante.
# cd /var/yp # cp ypxfr.log ypxfr.log.old # cat /dev/null > /var/yp/ypxfr.log
crontab peut exécuter ces commandes une fois par semaine. Pour désactiver la journalisation, supprimez le fichier journal.