Hostnames - De quoi s'agit-il?
J'ai récemment été "forcé" d'effectuer un travail d'administrateur système, alors que ce n'est pas quelque chose que j'aime absolument faire, j'ai beaucoup lu, expérimenté et appris.
Il y a un aspect fondamental de la configuration du serveur que je n'ai pas pu saisir - les noms d'hôte .
Dans Ubuntu par exemple, on devrait définir le nom d'hôte comme ceci (selon la Linode Library ):
echo "plato" > /etc/hostname
hostname -F /etc/hostname
Fichier: /etc/hosts
127.0.0.1 localhost.localdomain localhost
12.34.56.78 plato.example.com plato
Je suppose que plato est un nom arbitraire et que plato.example.com est le nom de domaine complet.
Maintenant mes questions sont:
- Est-ce obligatoire?
- Dans quel but?
- Où est-il nécessaire/utilisé?
- Pourquoi ne puis-je pas définir "localhost" comme nom d'hôte pour chaque machine?
- Dois-je configurer une entrée DNS pour le
plato.example.comFQDN? - Devrait
plato.example.comêtre utilisé comme entrée DNS inversée pour mon IP?
Existe-t-il également des "meilleures pratiques" pour choisir les noms d'hôtes? J'ai vu des gens utiliser des lettres grecques, des noms de planète et même des figures mythologiques ... Que se passe-t-il lorsque nous manquons de lettres/planètes?
Je suis désolé si c'est une question stupide mais je n'ai jamais été trop enthousiaste avec les configurations réseau.
De nos jours, un système peut avoir plusieurs interfaces, chacune avec plusieurs adresses, et chaque adresse peut même avoir plusieurs entrées DNS associées. Que signifie donc un "nom d'hôte système"?
De nombreuses applications utilisent le nom d'hôte du système comme identifiant par défaut lorsqu'elles communiquent ailleurs. Par exemple, si vous collectez des messages syslog sur un serveur central, tous les messages seront étiquetés avec le nom d'hôte du système d'origine. Dans un monde idéal, vous ignorez probablement cela (car vous ne voulez pas nécessairement faire confiance au client), mais le comportement par défaut - si vous avez nommé tous vos systèmes "localhost" - entraînerait un tas de messages de journal que vous ne serait pas en mesure de s'associer à un système spécifique.
Comme d'autres l'ont souligné, le nom d'hôte du système est également un identifiant utile si vous vous trouvez à accéder à distance à un certain nombre de systèmes. Si vous avez cinq fenêtres attachées à un système nommé "localhost", vous aurez du mal à les garder droites.
Dans la même veine, nous essayons de faire correspondre le nom d'hôte du système au nom d'hôte que nous utilisons pour l'accès administratif à un système. Cela permet d'éviter toute confusion lors de la référence au système (par e-mail, conversations, documentation, etc.).
Concernant DNS:
Vous voulez avoir des entrées DNS avant et arrière appropriées pour vos applications afin d'éviter toute confusion. Vous avez besoin de certains entrée vers l'avant (nom -> adresse IP) pour que les gens puissent accéder facilement à votre application. Avoir la correspondance d'entrée inversée est utile pour un certain nombre de raisons - par exemple, cela vous aide à identifier correctement l'application si vous trouvez l'adresse IP correspondante dans un journal.
Notez que je parle ici d '"applications" et non de "systèmes", car - en particulier avec les serveurs Web - il est courant d'avoir plusieurs adresses IP sur un système, associées à différents noms d'hôtes et services.
Essayer de conserver le nom des mappages IP dans votre /etc/hosts le fichier devient rapidement difficile car vous gérez un nombre croissant de systèmes. Il est très facile pour le fichier d'hôtes local de se désynchroniser par rapport au DNS, ce qui peut entraîner une confusion et dans certains cas un dysfonctionnement (car quelque chose essaie de se lier à une adresse IP qui n'existe plus sur le système, par exemple).
Vous pouvez définir chaque nom d'hôte sur "localhost", mais il est très pratique d'avoir alix@plato ~ $ dans votre invite de commande lorsque vous gérez des machines via ssh. La gestion des serveurs à distance peut devenir très déroutante si vous ne le faites pas.
Il est important d'avoir un nom de domaine complet correct lorsque vous hébergez un serveur Web ou un serveur de messagerie. Ces types d'applications serveur aiment savoir "sur qui" elles s'exécutent.
Pour choisir un bon schéma de nommage, je vous renvoie à cette question très populaire .
Un nom de domaine complet n'est utile que lorsqu'il est significatif pour un autre ordinateur. Il existe trois niveaux:
- Un ordinateur de votre réseau local a une entrée dans son fichier d'hôtes qui pointe vers cette machine
- Vous avez un serveur DNS en cours d'exécution sur votre réseau local et chaque ordinateur local qui l'utilise comme serveur DNS connaît désormais plato par son nom.
- Vous enregistrez un nom de domaine et maintenant le monde entier sait sur quelle machine pointe le nom plato.alixaxel.com.
Lors de l'envoi d'e-mails ou de la diffusion de pages Web vers le monde extérieur, la troisième est celle que vous souhaitez avoir. Pour la plupart des autres cas, vous pouvez vous contenter d'un DNS local ou même éditer des fichiers hôtes.
Dans ce cas, vous pouvez simplement créer un nom de domaine (plato.alixnetwork pourrait convenir comme nom de domaine complet) pour une utilisation au sein de votre réseau local. La seule valeur ajoutée d'avoir la partie "alixnetwork" (le nom de domaine) est la commodité lorsque vous avez un autre réseau local dont vous souhaitez le distinguer.
Un aperçu de base. Les noms d'hôte ne sont que des pointeurs; vous pouvez en attribuer un spécifique comme nom d'hôte référencé par la machine, mais il peut en avoir plusieurs. Certains services, notamment le courrier électronique et HTTP s'appuient sur des noms de domaine pour savoir où les services doivent être situés et comment y accéder.
Il y a longtemps, tous ces noms (qui, encore une fois, ne sont que des pointeurs vers des adresses IP) étaient conservés dans un fichier appelé hosts. Au fur et à mesure que le système a grandi, ils n'ont pas pu garder le fichier synchronisé sur tous les ordinateurs concernés participant aux différents réseaux interconnectés. Le système DNS a donc été inventé. Lorsque vous effectuez une recherche de nom, il vérifie toujours le fichier d'hôtes d'abord, puis le système DNS. Windows peut également vérifier d'autres systèmes comme WINS ou NetBIOS.
Lorsque vous placez une entrée dans un fichier hosts, vous ne l'affectez pas à l'ordinateur. L'attribution d'un nom d'hôte comme celui utilisé par l'ordinateur se fait dans les fichiers de configuration (sur les systèmes * nix) et les propriétés système dans les systèmes Windows (le système Windows peut également avoir NIC suffixes spécifiques).
Les entrées du fichier hosts, comme le système DNS, ne sont qu'un mappage d'un nom d'hôte à une adresse IP. Pour utiliser le nom d'hôte 'localhost' (il n'y a rien de spécial, c'est un nom d'hôte comme tous les autres), il doit être mappé à l'interface de bouclage (il pointera donc toujours vers l'ordinateur local). Pour garantir que cela fonctionne, tous les ordinateurs sont fournis avec ce mappage par défaut dans leur fichier hosts, mais il pourrait être supprimé si vous ne vouliez pas pouvoir utiliser ce nom d'hôte.
De plus, comme d'autres l'ont noté, il est très utile d'attribuer un nom d'hôte à un ordinateur. Une fois connecté à l'ordinateur, vous pouvez lui faire afficher son nom d'hôte lorsque vous vous connectez, ou en tant qu'invite, ou n'importe quel nombre d'autres endroits. Cela facilite l'identification de l'ordinateur auquel vous êtes connecté. Si vous configurez ce nom d'hôte dans DNS ou le placez dans tous les fichiers hosts, vous pourrez vous connecter à l'ordinateur en référençant son nom d'hôte au lieu d'avoir à connaître son adresse IP à tout moment. (Encore plus utile si l'ordinateur utilise DHCP, car l'adresse pourrait changer. Si l'ordinateur met à jour DNS, l'enregistrement DNS pointera vers la nouvelle adresse IP; vous pouvez toujours vous connecter sans connaître la nouvelle adresse IP car vous connaissez le nom DNS ).
Il existe de nombreuses autres utilisations de hosts et de DNS, mais je suppose que vous avez plus de questions que de réponses si vous lisez tout cela.
Chaque hôte doit recevoir un nom significatif. Le nom d'hôte peut servir à plusieurs fins:
1- Il vous aide à reconnaître sur lequel vous travaillez actuellement.
2- Utilisation de noms configurés dans /etc/hosts et/ou les enregistrements DNS sont plus faciles que de mémoriser de nombreuses adresses IP.
3- Localhost est un nom réservé pour faire référence à la machine actuelle (adresse 127.0.0.1).
4- Les enregistrements DNS sont utiles pour rendre vos serveurs accessibles au public.
Le choix d'un nom approprié pour chaque serveur vous aide beaucoup dans votre administration. En outre, cela aide vos clients à accéder à vos serveurs.
Juste comme remarque: travailler correctement la résolution DNS avant et arrière est la pierre angulaire absolue de chaque installation informatique sur cette planète. Ne sous-estimez jamais la nécessité d'un DNS bien entretenu et d'une bonne résolution de nom d'hôte!
Avertissement: la question principale concerne les systèmes Linux, alors n'hésitez pas à ignorer cette réponse si vous n'êtes pas intéressé par le côté Windows du problème.
Quoi qu'il en soit, dans les systèmes Windows, en dehors de tous les points mentionnés dans d'autres réponses, le nom d'hôte est effectivement utilisé par l'O.S. lui-même, à des fins de mise en réseau et d'authentification; Plus précisément:
- Chaque système, qu'il soit membre du domaine ou non, doit avoir un nom unique dans le même résea (c'est-à-dire dans le même sous-réseau IP), sinon un conflit de noms s'ensuivra et divers services réseau (principalement partage de fichiers et d’impressions) ne fonctionnera pas.
- Tous les systèmes qui sont membres du même domaine Active Directory doivent avoir un nom unique, indépendamment des limites du réseau.
- Dans un environnement de domaine, le nom d'hôte d'un système agit comme un principal de sécurité et peut être utilisé pour l'authentification à distance (il suffit de le considérer comme un compte utilisateur pour la machine); il peut se voir attribuer des autorisations et des droits d'accès et peut être placé dans des groupes à des fins de sécurité. Cela affecte tous les processus en cours d'exécution sur le système à l'aide des comptes d'utilisateur
LocalSystemetNetworkServiceintégrés, qui peuvent s'authentifier auprès d'autres systèmes à l'aide des informations d'identification du système sur lequel ils s'exécutent; cela permet f.e. un processus s'exécutant en tant queNetworkServicesur SystemA pour accéder à un dossier partagé sur SystemB en accordant des autorisations sur le dossier au compte d'utilisateur de SystemA.