> * Sur les machines Unix (HP, Sun, Linux RedHat/Slackware) que j'ai utilisees > jusqu'à présent, le service NIS/YP utilise le fichier /etc/nsswitch.conf, et le > DNS le fichier /etc/resolv.conf. Inexact.
Ces deux fichiers ne correspondent pas à des services, mais à des approches de fonctionnement du resolver. Les resolver type NIS+ utilisent /etc/nsswitch.conf : l'approche centralisée. Avantage : vision claire des sources utilisées et de leur priorités. Inconvénient : des «overrides» restent possible localement, ce qui brise l'intérêt d'avoir un système centralisé (exemple : yp). Ensuite, dans notre cas, la configuration de la «source» dns se fait dans les fichiers de configuration du dns, /etc/resolv.conf, dans lequel la ligne «order toto, tata» est ignorée. Les resolver plus anciens n'utilisent pas /etc/nsswitch.conf, ce fichier n'existe pas. Chaque service indique directement au sein de sa configuration quelles sources employer et dans quel ordre : /etc/passwd et /etc/group auront des lignes «en dur» (données locales), des lignes en «+» ou «-» (accès yp), etc. Pour le cas de /etc/hosts, il est possible (avec un bon resolver) d'y placer des lignes d'accès yp et/ou hesiod (commençant par [EMAIL PROTECTED]). Mais l'utilisation ou non d'un dns, et sa priorité par rapport aux autres sources est spécifiée historiquement dans /etc/resolv.conf, et cette-fois ci la ligne «order» importe. Dans les deux cas, c'est le bordel... il y en a juste un qui est plus propre. Pour l'anecdote, il y a plein d'histoires d'horreur avec le resolver de SunOS 4, qui n'utilisait pas yp *et* dns (l'un ou l'autre, mais pas les deux à la fois). Il fallait soit truquer son serveur yp pour que celui-ci émette les requêtes dns, soit compiler et installer un autre resolver (les instructions étaient tout de même fournies...) Miod Linux-Azur : http://www.linux-azur.org Désinscriptions: http://www.linux-azur.org/liste.php3 **** Pas de message au format HTML, SVP ****
