Avant le 17.1, le STCP résolvait les noms d'hôtes en interrogeant d'abord tout DNS configuré et ne recherchait le fichier local des hôtes que s'il n'y avait pas de réponse ou si les serveurs de noms donnaient une réponse négative.
À partir de la version 17.1, vous avez maintenant la possibilité de rechercher d'abord le fichier d'hôtes local, mais il y a certaines conditions. Tout d'abord, votre application doit être construite selon les règles POSIX sur un système 17.1. L'ensemble des commandes standard dans >system>stcp>command_library sont toutes construites de cette manière mais vous ne pouvez pas simplement installer 17.1 sans reconstruire vos applications et espérer utiliser cette fonctionnalité. Ensuite, vous devez installer le fichier de configuration Name Service Switch, nsswitch.conf, dans le répertoire >system>stcp. Une version par défaut du fichier se trouve dans le répertoire >system>stcp>templates.
Comme vous pouvez le voir sur la figure 1, le fichier nsswitch.conf semble contrôler toutes sortes de choses. Cependant, seules les entrées "hosts" et "networks" ont un effet sur le comportement du système. L'ordre des mots clés "dns" et "files" contrôle l'ordre de recherche. Si "files" vient en premier, le fichier "hosts" ou "networks" sera recherché avant d'interroger le DNS. Si "dns" vient en premier, le DNS sera interrogé avant de rechercher les fichiers. Si l'entrée "hosts" ou "networks" ne comprend qu'un seul des mots clés, seule la recherche correspondant à ce mot clé sera effectuée.
La raison principale de l'utilisation du fichier hosts au lieu d'une simple interrogation du DNS est la vitesse/récupération après sinistre et le contrôle. Comme le montre l'exemple 1, lorsque l'un des serveurs de noms ne répond pas, le temps de résolution du nom passe de 20 millisecondes à près de 2 secondes. Si aucun de vos serveurs de noms ne répond, le temps de résolution du nom peut être très long (exemple 2). En plaçant les noms critiques dans le fichier hosts et en effectuant d'abord une recherche dans le fichier hosts, vous n'avez pas à vous soucier du temps nécessaire à la résolution des noms (exemple 3).
Une autre raison de rechercher d'abord le fichier hôte est le contrôle local. Lorsque vous utilisez un DNS, vous renoncez au contrôle du processus de résolution du nom. Dans la plupart des cas, cela fonctionne sans problème, mais parfois un contrôle local est nécessaire. Par exemple, s'il devient nécessaire de bloquer temporairement ou définitivement l'accès à un hôte, vous pouvez le faire au niveau du pare-feu ou en redirigeant les demandes vers un hôte à problème vers une adresse différente en modifiant la base de données DNS ou le fichier hosts. Il peut ne pas être possible de modifier la base de données DNS et les modifications apportées au pare-feu peuvent prendre trop de temps, mais vous pouvez modifier votre propre fichier hosts. L'exemple 4 montre que l'accès à www.google.com est redirigé vers un hôte local.
L'inconvénient du fichier hosts est que la correspondance entre les noms d'hôtes et les adresses IP est statique. Comme le montre l'exemple 5, les serveurs de noms peuvent être configurés pour fournir différentes adresses IP afin de répartir la charge entre plusieurs serveurs d'applications. Si vous ajoutez une entrée dans le fichier hosts, cette entrée est statique et vous perdez le bénéfice de tout équilibrage de charge que le DNS pourrait fournir. En outre, vous devez maintenir manuellement le fichier hosts si/quand les adresses IP des hôtes sont modifiées.
Alors comment configurer le fichier nsswitch.conf. Les commentaires du fichier (figure 1) suggèrent de ne pas installer le fichier dans le répertoire >system>stcp avant que toutes vos applications aient été reconstruites pour l'utiliser. Cela évitera d'éventuels résultats divergents où l'ancienne application utilise le DNS obtenant une adresse alors que les nouvelles applications utilisent le fichier hosts obtenant une adresse différente (exemple 4). En outre, comme le DNS a toujours été interrogé en premier, il est tout à fait possible que certaines entrées d'un fichier hosts existant ne soient plus correctes. Une stratégie alternative consiste à installer le fichier avec l'entrée hosts définie sur "files dns" mais en s'assurant que la seule entrée dans le fichier hosts est localhost (exemple 6). Vous pouvez alors ajouter des adresses host /IP au fichier hosts si nécessaire avec un minimum de modifications, en gardant à l'esprit que toute ancienne application ne verra pas l'adresse du fichier hosts.
OK, et les réseaux ? Il a toujours été possible de donner un nom à un réseau en le plaçant dans le fichier >system>stcp>networks. Personnellement, je n'en ai jamais vu la nécessité, mais vous pourriez utiliser un nom lorsque vous ajoutez une route. Il est intéressant de noter que le nom n'est pas affiché lorsque vous imprimez des itinéraires (exemple 7). Vous pouvez également utiliser un nom lorsque vous utilisez l'argument -network dans la commande arp. Le fichier nsswitch.conf par défaut pour les réseaux recherche d'abord dans le fichier des réseaux, puis interroge le DNS. À moins que votre DNS ne soit effectivement configuré pour renvoyer des informations sur le nom du réseau, je vous suggère de supprimer le mot-clé dns de l'entrée "networks".
Un dernier point. J'ai inclus deux exemples de programmes. Le premier resolve.c utilise l'ancienne fonction de résolution de nom gethostbyname ; le second, new_resolve.c utilise la nouvelle fonction getaddrinfo. La fonction gethostbyname a été remplacée par la fonction standard POSIX getaddrinfo. Comme il s'agit de la norme POSIX, vous ne trouverez aucune documentation sur getaddrinfo dans Stratadoc ; cependant, il y a beaucoup de documentation sur le web, il suffit de googler getaddrinfo.
Exemples :
Dans les exemples suivants, les programmes resolve_17.0 et resolve sont basés sur le même code source. La seule différence est que resolve_17.0 a été compilé sur un système VOS 17.0 alors que resolve a été compilé sur un système 17.1. Les serveurs de noms 1.1.1.1, 1.1.1.2, et 1.1.1.3 sont des fictions et sont utilisés pour simuler un serveur de noms qui ne répond pas. J'ai également supprimé les numéros d'hôtes qui ne sont pas sur un réseau public.
d >system>stcp>resolv.conf -match nameserver %phx_vos#m16_mas>system>stcp>resolv.conf 11-05-24 08:07:13 mst nameserver 164.152.XXX.XXX nameserver 134.111.XXX.XXX prêt 08:07:13 resolve_17.0 ftp.stratus.com ftp.stratus.com résolu à 192.52.248.14 en 20.615 ms prêt 08:07:20 d >system>stcp>resolv.conf -match nameserver %phx_vos#m16_mas>system>stcp>resolv.conf 11-05-24 08:07:30 mst nameserver 1.1.1.1 nameserver 164.152.XXX.XXX nameserver 134.111.XXX.XXX prêt 08:07:30 resolve_17.0 ftp.stratus.com ftp.stratus.com résolu à 192.52.248.14 en 1989.395 ms prêt 08:07:38 |
| Exemple 1 - changement d'heure lorsqu'un serveur de nom (1.1.1.1) ne répond pas |
d >system>stcp>resolv.conf -match nameserver
%phx_vos#m16_mas>system>stcp>resolv.conf 11-05-23 13:11:31 mst
nameserver 1.1.1.1
serveur de noms 1.1.1.2
serveur de noms 1.1.1.3
prêt 13:11:31
resolve_17.0 ftp.stratus.com
ftp.stratus.com résolu à 192.52.248.14 en 14759.949 ms
prêt 13:12:13
|
| Exemple 2 - délai de résolution d'un nom lorsqu'aucun serveur de noms ne répond |
d >system>stcp>resolv.conf -match nameserver %phx_vos#m16_mas>system>stcp>resolv.conf 11-05-24 08:18:10 mst nameserver 1.1.1.1 nameserver 164.152.XXX.XXX nameserver 134.111.XXX.XXX prêt 08:18:10 d >system>stcp>nsswitch.conf -match hosts : %phx_vos#m16_mas>system>stcp>nsswitch.conf 11-05-24 08:18:21 mst hôtes : fichiers dns prêt 08:18:21 résoudre ftp.stratus.com ftp.stratus.com résolu à 192.52.248.14 en 13.702 ms prêt 08:18:31 résoudre www1.stratus.com www1.stratus.com résolu à 134.111.1.84 en 227.798 ms prêt 08:18:39 |
| Exemple 3 - différence de temps entre la première recherche dans le fichier d'accueil et la recherche/absence d'une entrée |
d >system>stcp>resolv.conf -match nameserver %phx_vos#m16_mas>system>stcp>resolv.conf 11-05-23 13:28:51 mst nameserver 164.152.XXX.XXX nameserver 134.111.XXX.XXX prêt 13:28:51 d %phx_vos#m16_mas>system>stcp>hosts -match google %phx_vos#m16_mas>system>stcp>hosts 11-05-23 13:29:29 mst 127.0.0.1 www.google.com google.com google prêt 13:29:29 resolve_17.0 www.google.com www.google.com a décidé de 74.125.226.115 en 180.099 ms prêt 13:29:40 résoudre www.google.com www.google.com a décidé de 127.0.0.1 à 13.458 ms prêt 13:30:01 |
| Exemple 4 - blocage de l'accès à www.google.com en changeant son adresse en localhost pour les nouvelles applications |
résoudre www.yahoo.com www.yahoo.com a décidé de 67.195.160.76 en 21.439 ms prêt 13:35:56 résoudre www.yahoo.com www.yahoo.com a décidé de 69.147.125.65 en 21.713 ms prêt 13:35:56 résoudre www.yahoo.com www.yahoo.com a décidé de 67.195.160.76 en 30.106 ms prêt 13:35:57 résoudre www.yahoo.com www.yahoo.com a décidé de 69.147.125.65 en 29.739 ms prêt 13:35:58 résoudre www.yahoo.com www.yahoo.com a décidé de 67.195.160.76 en 23.880 ms prêt 13:35:58 résoudre www.yahoo.com www.yahoo.com a décidé de 69.147.125.65 en 22.736 ms prêt 13:35:58 |
| Exemple 5 - Le DNS fournit plusieurs adresses IP |
d >système>stcp>hôtes %phx_vos#m16_mas>system>stcp>hosts 11-05-24 08:32:51 mst # # Exemple de fichier d'hôtes # # adresse IP nom alias # commentaire(s) # 127.0.0.1 localhost loopback-host loopback lb # requis prêt 08:32:51 |
| Exemple 6 - fichier d'hôtes minimum |
route ajouter noahs-test 164.152.XXX.XXX 5.255.255.0 prêt 13:52:54 impression de l'itinéraire Passerelle par défaut : 164.152.XXX.XXX Passerelle d'adresse réseau Masque de sous-réseau Redirection de la vie 1.2.3.0 164.152.XXX.XXX 255.255.255.0 prêt 13:53:26 d networks -match noahs-test %phx_vos#m16_mas>system.17.1>stcp>networks 11-05-23 13:53:48 mst noahs-test 1.2.3.0 prêt 13:53:48 |
| Exemple 7 - ajout d'un réseau en utilisant un nom dans le tableau des réseaux |
# # Exemple nsswitch.conf(5) - fichier de configuration du commutateur de service de nom # # Ce fichier de configuration n'est utilisé que par les programmes qui ont été construits # selon les règles POSIX dans la version 17.1 ou ultérieure. Si cette configuration # n'est pas présent, les recherches de nom d'hôte seront compatibles avec le # les anciennes versions du logiciel DNS. Pour éviter toute confusion, nous # vous recommande de reporter l'utilisation de ce fichier de configuration jusqu'à ce que tous # les applications ont été reconstruites en utilisant POSIX. # # Le logiciel DNS non-POSIX (et tous les logiciels DNS avant la publication # 17.1) a résolu les hôtes en utilisant d'abord le DNS et ensuite le # >system>stcp>hosts file. Cela pose quelques problèmes mineurs : # # 1. S'il y a une mauvaise entrée dans le fichier hosts, il n'obtiendra pas # détecté jusqu'à ce que quelque chose fasse disparaître le DNS. Ce # pourrait entraîner une confusion au moment précis où on ne le souhaite pas. # # 2. Il n'y a aucun moyen de passer outre un mauvais hôte qui revient du DNS. # # 3. La plupart des autres implémentations recherchent d'abord le fichier hôte. # # Aucun d'entre eux n'est assez convaincant pour effectuer un changement incompatible # au comportement par défaut ; cependant, vous pouvez changer l'ordre de recherche # utiliser ce fichier pour éviter les problèmes ci-dessus. Pour rechercher le fichier hosts # d'abord, vous voulez : # # hôtes : fichiers dns # # de faire le DNS en premier et de rester 100% compatible avec le comportement de # les versions précédentes de VOS, vous voulez : # # hôtes : fichiers dns # # Notez également que les logiciels non-POSIX et antérieurs à 17.1 n'ont jamais utilisé de dns pour # recherche de réseaux. C'est ce que fait le nouveau logiciel. Par défaut, il fait ceci # après avoir regardé dans le fichier >system>stcp>networks. On peut configurer # ce comportement aussi. Il n'y a généralement pas beaucoup d'informations utiles qui # revient du DNS pour les réseaux. Si vous voulez désactiver les consultations DNS # pour les réseaux, faites ceci : # # réseaux : fichiers # groupe : compat group_compat : nis hôtes : fichiers dns réseaux : fichiers dns passwd : compat passwd_compat : nis shells : fichiers services : compat services_compat : nis protocoles : fichiers rpc : fichiers |
| Figure 1 - Fichier nsswitch.conf par défaut trouvé dans >system>stcp>templates |
#define _POSIX_C_SOURCE 200112L
#include <netdb.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main (argc, argv)
int argc;
char *argv [];
{
struct hostent *hInfo; /* used to hold host information
including IP address after
resolving hostname */
long long jJiffy1; /* starting jiffy time */
long long jJiffy2; /* ending jiffy time */
extern void s$read_jiffy_clock(long long *);
double milliseconds; /* ms between jJiffy2 & jJiffy1 */
/* process arguments. If we don't have exactly the right number of
arguments print out a usage message, a version message and exit */
if (argc != 2)
{
printf ("Usage:ntresolve hostnamen");
exit (0);
}
/* Take a timestamp, resolve the name and take another timestamp */
s$read_jiffy_clock (&jJiffy1);
hInfo = gethostbyname (argv [1]);
s$read_jiffy_clock (&jJiffy2);
milliseconds = (jJiffy2 - jJiffy1) / 65.536;
if (hInfo == NULL)
printf ("nCould not resolve the address of %s - %3.3f msn",
argv [1], milliseconds);
else
{
printf ("%s resolved to %s in %3.3f msn", argv [1],
inet_ntoa (*(struct in_addr *)(hInfo -> h_addr_list [0])),
milliseconds);
}
endhostent ();
}
|
| Figure 2 - resolve.c utilise l'ancienne fonction gethostbyname |
#define _POSIX_C_SOURCE 200112L
#include <netdb.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <stdio.h>
int main (argc, argv)
int argc;
char *argv [];
{
struct addrinfo *addressInfo; /* used to hold host information */
struct sockaddr_in *sin; /* template to extract addr info */
int error;
long long jJiffy1; /* starting jiffy time */
long long jJiffy2; /* ending jiffy time */
extern void s$read_jiffy_clock(long long *);
double milliseconds; /* ms between jJiffy2 & jJiffy1 */
char szIP [16]; /* holds printable IP address */
/* process arguments. If we don't have exactly the right number of
arguments print out a usage message, a version message and exit */
if (argc != 2)
{
printf ("Usage:ntresolve hostnamen");
exit (0);
}
/* Take a timestamp, resolve the name and take another timestamp */
s$read_jiffy_clock (&jJiffy1);
error = getaddrinfo (argv [1], NULL, NULL, &addressInfo);
s$read_jiffy_clock (&jJiffy2);
milliseconds = (jJiffy2 - jJiffy1) / 65.536;
if (error != 0)
printf ("nCould not resolve the address of %s - %3.3f msn",
argv [1], milliseconds);
else
{
if (inet_ntop (AF_INET,
&(((struct sockaddr_in *)(addressInfo->ai_addr))->
sin_addr.S_un.S_addr), szIP, 16) == NULL)
printf ("Could not convert address %xn",
(((struct sockaddr_in *)(addressInfo->ai_addr))->
sin_addr.S_un.S_addr));
else
printf ("%s resolved to %s in %3.3f msn",
argv [1], szIP, milliseconds);
}
freeaddrinfo (addressInfo);
}
|
| Figure 3 - new_resolve.c utilise la nouvelle fonction getaddrinfo de la norme POSIX |
Entreprise