Le Mardi 27 Septembre 2005 17:24, CC a écrit : > Selon tzacos <[EMAIL PROTECTED]>: > > CC a écrit : > > >Selon tzacos <[EMAIL PROTECTED]>: > > >>>Le but de la manoeuvre étant d'avoir un serveur "autonome" capable de > > >>>fonctionner même en l'absence du lien réseau distant, cette solution > > > > n'était > > > > >>>pas envisageable. Le mappage statique répond tout-à-fait au problème : > > >> > > >>résoudre > > >> > > >>>le nom netbios du serveur de messagerie et du contrôleur principal du > > >> > > >>domaine. > > >> > > >>>J'aurais pu installer un dns local pour résoudre ces noms localement, > > >>> mais > > >> > > >>c'est > > >> > > >>>un peu un marteau pilon pour écraser une mouche ! > > >> > > >>ben le wins est à peine moins marteau pilon. > > > > > >fait partie de samba, rien de plus à installer; le code correspondant > > > est > > > > court > > > > >et simple, pas de charge système. wins est bien adapté à la résolution > > > des > > > > noms > > > > >netbios sur un segment de réseau. pas trop marteau pilon à mon avis > > > > > >>Surtout qu'il n'est pas capable de distinguer les domaines DNS (i.e.: > > >>subdomain.domain.tld), et que les informations disponibles sont > > >>nettement moins nombreuses. Par exemple, oubliez un AD avec un wins > > >> seul. > > > > > >AD est conçu pour utiliser un dns pour la résolution des noms, c'est > > > donc > > > > normal > > > > >! > > >Les informations nécessaires dans beaucoup de petites boites sont > > > limitées > > > > et > > > > >peuvent être totalement couvertes par dhcp (dns, passerelle, wins...) et > > > par wins (noms netbios, avec la possibilité des mappages statiques pour > > > > certaines > > > > >machines "statiques"). Mais tu as raison sur le fond. Ceci dit, un dns > > > est > > > > par > > > > >nature public et expose de manière plus globale les noms de machines que > > > > wins > > > > >(qui reste limité en général au segment local) > > > > C'est c'est une question de configuration. DNS permet de distinguer la > > visibilité des informations par ACL. Donc tu peux avoir un DNS qui sert > > un certain nombre de zones et dont la visibilité est assuré par le > > système ses vues qui se base sur des ACL pour savoir qui peut voir quoi. > > > > Il ne faut pas oublier que WINS n'est pas un resolver de nom mais un > > resolver de nom NetBIOS. si pas de NetBIOS (qui est une API, et NetBUI > > le protocole) pas de résolution. Du coup cela pose un probleme pour les > > machines Unix qui ne peuvent plus utiliser les outils natif pour faire > > leur résolution. Car DNS resout les noms pour Winsock. Et la resolution > > fait directement appel à la pile TCP/IP. Pas la resolution WINS qui doit > > fait appel à l'API NetBIOS pour resoudre les noms. > > Même sur une petite infrastructure professionnelle, je ne trouve que ce > > soit du bon boulot que d'être obligé de mettre une API NetBIOS sur un > > Solaris par exemple. > > > > Si le DNS est bien concu, il n'y a aucune raison d'avoir besoin d'un > > WINS. en tout cas pas dans une petite structure. Voire meme dans une > > grande d'ailleurs. Le problème viend le plus souvent d'une mauvaise > > configuration du client. > > > > Si vous activez "Autoriser DNS pour résoudre les nom NetBIOS" dans la > > configuration TCP/IP, pas besoin de WINS car c'est le DNS qui fera le > > boulot. et ainsi tout deviend cohérent. > > > > D'autant plus qu'il existe des serveurs DNS facile à installer et à > > configurer, pour ceux qui aurait peur du Bind ISC. Sachant qu'un Bind > > ISC bien configuré et installé, sur une Mandriva, ca prend une heure à > > faire. Et au moins c'est capable d'intégrer la mise à jour dynamique des > > noms (DDNS) avec un DHCP par exemple d'une facon bien plus fiable que le > > WINS. > > En plus, WINS n'est pas performant dans un modèle distribué, alors que > > le DNS est concu pour ça. > > C'est toujours le même problème: Doit on considérer l'infrastructure > > actuelle comme figée, ou au contraire doit on prendre en compte des > > évolution qui risquent de conduire les choix d'aujourd'hui dans une > > mauvaise directioin et nécessiter de passer à autre chose et donc de > > dépenser du temps, des ressources et éventuellement de l'argent, en plus > > de ce qui aura déjà été" dépensé? > > > > Enfin, ce que j'en dit moi ;) :D > > > > WINS est une technologie obsolète, développée à l'époque (1983 il em > > semble ou meme avant) par ce qu'il n'y avait rien. > > DNS est arrivé après et colle mieux à un modèle distribué, et en plus > > capable de gérer des problématiques privée/publique. WINS ne gère pas > > cette problématique. Pire elle l'ignore et de là permet la fuite > > d'information importante pour un attaquant ou une personne mal > > intentionnée. > > > > laurent > > D'accord avec toi sur le fond. > mais : > - je n'y connait rien en dns > - il y a déjç un dns (sous NT) sur le réseau auquel je n'ai pas accès > - je ne souhaite pas que les noms de machines aient une entrée dns > - je n'ai que trois noms netbios à résoudre > - je n'ai pas trouvé comment configurer dhcp pour activer la résolution > netbios par wins > > Donc pour l'instant, la solution wins est la seule à ma portée. Mais je > tiens compte de tes remarques et ton aide me sera précieuse pour passer à > dns. > > -- > CC J' ai récemment remplacé les contrôleur de ma mairie par un Samba et j' ai eu un souci équivalent parce que ces boeufs de machines clientes avaient toujours en mémoire quelque part l' ancien contrôleur; voici ma solution. J' ai installé sur un autre serveur Linux dnsmasq; c' est un programme qui fait dns relay et dhcp serveur et j' ai servi l' adresse de mon Samba par dhcp.
Voici un petit extrait de dnsmasq.conf relatif a cela -------------------------------- # The following DHCP options set up dnsmasq in the same way as is specified # for the ISC dhcpcd in # http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt # adapted for a typical dnsmasq installation where the host running # dnsmasq is also the host running samba. # you may want to uncomment them if you use Windows clients and Samba. #dhcp-option=19,0 # option ip-forwarding off #dhcp-option=44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s) #dhcp-option=45,0.0.0.0 # netbios datagram distribution server #dhcp-option=46,8 # netbios node type #dhcp-option=47 # empty netbios scope. -------------------------------- Et nickel chrome tout est reparti. Nota: dnsmasq vient de la Debian (je pense) mais je croit qu' il existe maintenant en RPM pour MDV (peut-être dans contrib) sans cela descend les sources et easy il suffit de renseigner dnsmasq.conf et de le démarrer. JPB
____________________________________________________ Want to buy your Pack or Services from Mandriva? Go to http://store.mandriva.com Join the Club : http://www.mandrivaclub.com ____________________________________________________
