Chapitre 30. Serveurs réseau

On fait parfois référence à inetd(8) comme étant le "super-serveur Internet" parce qu’il gère les connexions pour plusieurs services. Quand une connexion est reçue par inetd, ce dernier détermine à quel programme la connexion est destinée, invoque le processus en question et lui délègue la "socket" (le programme est invoqué avec la "socket" service comme entrée standard, sortie et descripteurs d’erreur). Exécuter inetd pour les serveurs qui ne sont pas utilisés intensément peut réduire la charge système globale quand on compare avec l’exécution de chaque "daemon" individuellement en mode autonome.

inetd est utilisé pour invoquer d’autres "daemon"s, mais plusieurs protocoles triviaux sont gérés directement, comme chargen, auth, et daytime.

Cette section abordera la configuration de base d’inetd à travers ses options en ligne de commande et son fichier de configuration /etc/inetd.conf.

inetd est initialisé par l’intermédiaire du système rc(8). L’option inetd_enable est positionnée à la valeur NO par défaut, mais peut être activée par sysinstall lors de l’installation en fonction de la configuration choisie par l’utilisateur. Placer

ou

dans /etc/rc.conf activera ou désactivera le lancement d’inetd à la mise en route du système. La commande:

peut être lancée pour afficher le paramétrage en vigueur.

De plus, différentes options de ligne de commande peuvent être passées à inetd par l’intermédiaire de l’option inetd_flags.

Comme la plupart des "daemons", inetd possède de nombreuses options que l’on peut passer à son lancement afin de modifier son comportement. La liste complète des options se présente sous la forme:

inetd [-d] [-l] [-w] [-W] [-c maximum] [-C taux] [-a adresse | nom de machine] [-p fichier] [-R taux] [fichier de configuration]

Les options peuvent être passées à inetd en utilisant le paramètre inetd_flags dans /etc/rc.conf. Par défaut, inetd_flags contient -wW -C 60, qui active le "TCP wrapping" pour les services inetd, et empêche l’invocation d’un service plus de 60 fois par minute à partir d’une unique adresse IP.

Les novices seront heureux d’apprendre que ce paramétrage n’a en général pas besoin d’être modifié, cependant nous présentons ci-dessous les options de limitation du taux d’invocation étant donné que cela peut être utile si vous recevez une quantité excessive de connexions. Une liste complète d’options peut être trouvée dans la page de manuel de inetd(8).

La configuration d’inetd se fait par l’intermédiaire du fichier /etc/inetd.conf.

Quand le fichier /etc/inetd.conf est modifié, inetd peut être forcé de relire son fichier de configuration en utilisant la commande:

Chaque ligne du fichier de configuration ne mentionne qu’un seul "daemon". Les commentaires dans le fichier sont précédés par un "#". Le format de chaque entrée du fichier /etc/inetd.conf est le suivant:

Un exemple d’entrée pour le "daemon" ftpd(8) utilisant l’IPv4 ressemblerait:

En fonction des choix effectués à l’installation, plusieurs services peuvent être activés par défaut. S’il n’y a pas de raison particulière à l’utilisation d’un "daemon", envisagez de le désactiver. Ajoutez un caractère "#" devant le "daemon" en question dans le fichier /etc/inetd.conf, et ensuite rechargez la configuration d’inetd. Certains "daemon"s comme fingerd, devraient être évités parce qu’ils peuvent fournir des informations utiles aux personnes malveillantes.

Certains "daemon"s n’ont aucune conscience des problèmes de sécurité, et ont un long délai limite, ou pas du tout, d’expiration pour les tentatives de connexions. Cela permet à une personne malveillante d’envoyer régulièrement et de manière espacée des demandes de connexions à un "daemon" particulier, avec pour conséquence de saturer les ressources disponibles. Cela peut être une bonne idée de placer des limitations nb-max-connexions-par-ip-par-minute, max-child ou nb-max-enfants sur certains "daemon"s si vous trouvez que vous avez trop de connexions.

Par défaut, le "TCP wrapping" est activé. Consultez la page de manuel hosts_access(5) pour plus d’information sur le placement de restrictions TCP pour divers "daemon"s invoqués par inetd.

daytime, time, echo, discard, chargen, et auth sont des services fournis en interne par inetd.

Le service auth fournit les services réseau d’identification, et est configurable à un certain degré, alors que les autres services ne peuvent être que stoppés ou en fonctionnement.

Consultez la page de manuel de inetd(8) pour plus d’informations.

NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement.

Sur le serveur, les "daemons" suivants doivent tourner:

Le client peut également faire tourner un "daemon" connu sous le nom de nfsiod. Le "daemon" nfsiod traite les requêtes en provenance du serveur NFS. Ceci est optionnel, et améliore les performances, mais n’est pas indispensable pour une utilisation normale et correcte. Consultez la page de manuel nfsiod(8) pour plus d’informations.

La configuration de NFS est une opération relativement directe. Les processus qui doivent tourner peuvent tous être lancés au démarrage en modifiant légèrement votre fichier /etc/rc.conf.

Sur le serveur NFS, assurez-vous que les options suivantes sont configurées dans le fichier /etc/rc.conf:

mountd est automatiquement exécuté dès que le serveur NFS est activé.

Sur le client, assurez-vous que cette option est présente dans le fichier /etc/rc.conf:

Le fichier /etc/exports indique quels systèmes de fichiers NFS devraient être exportés (parfois on utilise le terme de "partagés"). Chaque ligne dans /etc/exports précise un système de fichiers à exporter et quelles machines auront accès à ce système de fichiers. En plus des machines qui auront accès, des options d’accès peuvent également être présentes. Ces options sont nombreuses mais seules quelques unes seront abordées ici. Vous pouvez aisément découvrir d’autres options en lisant la page de manuel exports(5).

Voici quelques exemples d’entrées du fichier /etc/exports:

Les exemples suivants donnent une idée de comment exporter des systèmes de fichiers bien que certains paramètres peuvent être différents en fonction de votre environnement et votre configuration réseau. Par exemple, pour exporter le répertoire /cdrom pour les trois machines d’exemple qui appartiennent au même domaine que le serveur (d’où l’absence du nom de domaine pour chacune d’entre elles) ou qui ont une entrée dans votre fichier /etc/hosts. Le paramètre -ro limite l’accès en lecture seule au système de fichiers exporté. Avec ce paramètre, le système distant ne pourra pas écrire sur le système de fichiers exporté.

La ligne suivante exporte /home pour les trois machines en utilisant les adresses IP. C’est une configuration utile si vous disposez d’un réseau privé sans serveur DNS configuré. Le fichier /etc/hosts pourrait éventuellement être configuré pour les noms de machines internes, consultez la page de manuel hosts(5) pour plus d’information. Le paramètre -alldirs autorise l’utilisation des sous-répertoires en tant que point de montage. En d’autres termes, il ne montera pas les sous-répertoires mais autorisera le client à ne monter que les répertoires qui sont nécessaires ou désirés.

La ligne suivante exporte /a pour que deux clients d’un domaine différent puissent y accéder. Le paramètre -maproot=root autorise l’utilisateur root du système distant à écrire des données sur le système de fichiers exporté en tant que root. Si le paramètre -maproot=root n’est pas précisé, même si un utilisateur dispose d’un accès root sur le système distant, il ne pourra pas modifier de fichiers sur le système de fichiers exporté.

Afin de pouvoir accéder à un système de fichiers exporté, le client doit avoir les permissions de le faire. Assurez-vous que le client est mentionné dans votre fichier /etc/exports.

Dans /etc/exports, chaque ligne représente l’information d’exportation d’un système de fichiers vers une machine. Une machine distante ne peut être spécifiée qu’une fois par système de fichiers, et ne devrait avoir qu’une seule entrée par défaut. Par exemple, supposons que /usr soit un seul système de fichiers. Le fichier /etc/exports suivant serait invalide:

Un système de fichiers, /usr, a deux lignes précisant des exportations vers la même machine, client. Le format correct pour une telle situation est:

Les propriétés d’un système de fichiers exporté vers une machine donnée devraient apparaître sur une ligne. Les lignes sans client sont traitées comme destinée à une seule machine. Cela limite la manière dont vous pouvez exporter les systèmes de fichiers, mais pour la plupart des gens cela n’est pas un problème.

Ce qui suit est un exemple de liste d’exportation valide, où les répertoires /usr et /exports sont des systèmes de fichiers locaux:

Le "daemon"mountd doit être forcé de relire le fichier /etc/exports à chacune de ses modifications, afin que les changements puissent prendre effet. Cela peut être effectué soit en envoyant un signal HUP au "daemon":

soit en invoquant la procédure rc(8) de mountd avec le paramètre approprié:

Veuillez consulter la Utilisation du système rc sous FreeBSD pour plus d’information sur l’utilisation des procédures rc.

De plus, un redémarrage permettra à FreeBSD de tout configurer proprement. Un redémarrage n’est cependant pas nécessaire. Exécuter les commandes suivantes en tant que root devrait mettre en place ce qui est nécessaire.

Sur le serveur NFS:

Sur le client NFS:

Maintenant il devrait être possible de monter un système de fichiers distant. Dans nos exemples le nom du serveur sera serveur et le nom du client client. Si vous voulez monter temporairement un système de fichiers distant ou vous voulez simplement tester la configuration, exécutez juste une commande comme celle-ci en tant que root sur le client:

Cela montera le répertoire /home situé sur le serveur au point /mnt sur le client. Si tout est correctement configuré vous devriez être en mesure d’entrer dans le répertoire /mnt sur le client et de voir tous les fichiers qui sont sur le serveur.

Si vous désirez monter automatiquement un système de fichiers distant à chaque démarrage de l’ordinateur, ajoutez le système de fichiers au fichier /etc/fstab. Voici un exemple:

La page de manuel fstab(5) liste toutes les options disponibles.

Certaines applications (par exemple mutt) ont besoin du verrouillage des fichiers pour fonctionner correctement. Dans le cas du NFS, rpc.lockd peut être utilisé pour assurer le verrouillage des fichiers. Pour l’activer, ajouter ce qui suit au fichier /etc/rc.conf sur les machines clientes et serveur (on suppose que les clients et le serveur NFS sont déjà configurés):

Lancez l’application en utilisant:

Si un verrouillage réel n’est pas nécessaire entre les clients et le serveur NFS, il est possible de laisser le client NFS effectuer le verrouillage localement en passant l’option -L à mount_nfs(8). Veuillez vous référer à la page de manuel mount_nfs(8) pour de plus amples détails.

Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentés ci-dessous:

amd(8) ("automatic mounter daemon"-"daemon" de montage automatique) monte automatiquement un système de fichiers distant dès que l’on accède à un fichier ou un répertoire contenu par ce système de fichiers. Les systèmes de fichiers qui sont inactifs pendant une certaine période seront automatiquement démontés par amd. L’utilisation d’amd offre une alternative simple aux montages permanents qui sont généralement listés dans /etc/fstab.

amd opère en s’attachant comme un serveur NFS aux répertoires /host et /net. Quand on accède à un fichier à l’intérieur de ces répertoires, amd recherche le montage distant correspondant et le monte automatiquement. /net est utilisé pour monter un système de fichiers exporté à partir d’une adresse IP, alors que /host est utilisé pour monter un système de fichiers exporté à partir d’un nom de machine distant.

Un accès à un fichier dans /host/foobar/usr demandera à amd de tenter de monter l’export /usr sur la machine foobar.

Comme on le voit dans l’exemple, showmount liste /usr comme une exportation. Quand on change de répertoire pour /host/foobar/usr, amd tente de résoudre le nom de machine foobar et de monter automatiquement le système exporté désiré.

amd peut être lancé par les procédures de démarrage en ajoutant les lignes suivantes dans le fichier /etc/rc.conf:

De plus, des paramètres peuvent être passés à amd à l’aide de l’option amd_flags. Par défaut, l’option amd_flags est possitionnée à:

Le fichier /etc/amd.map définit les options par défaut avec lesquelles les systèmes exportés sont montés. Le fichier /etc/amd.conf définit certaines des fonctionnalités les plus avancées de amd.

Consultez les pages de manuel de amd(8) et amd.conf(8) pour plus d’informations.

Certaines cartes Ethernet ISA présentent des limitations qui peuvent poser de sérieux problèmes sur un réseau, en particulier avec NFS. Ce n’est pas une particularité de FreeBSD, mais FreeBSD en est également affecté.

Ce problème se produit pratiquement à chaque fois que des systèmes (FreeBSD) PC sont sur le même réseau que des stations de travail très performantes, comme celles de Silicon Graphics, Inc. et Sun Microsystems, Inc. Les montages NFS se feront sans difficulté, et certaines opérations pourront réussir, puis soudain le serveur semblera ne plus répondre au client, bien que les requêtes vers ou en provenance d’autres systèmes continueront à être traitées normalement. Cela se manifeste sur la machine cliente, que ce soit le système FreeBSD ou la station de travail. Sur de nombreux systèmes, il n’est pas possible d’arrêter le client proprement une fois que ce problème apparaît. La seule solution est souvent de réinitialiser le client parce que le problème NFS ne peut être résolu.

Bien que la solution "correcte" est d’installer une carte Ethernet plus performante et de plus grande capacité sur le système FreeBSD, il existe une solution simple qui donnera satisfaction. Si le système FreeBSD est le serveur, ajoutez l’option -w=1024 lors du montage sur le client. Si le système FreeBSD est le client, alors montez le système de fichiers NFS avec l’option -r=1024. Ces options peuvent être spécifiées dans le quatrième champ de l’entrée fstab sur le client pour les montages automatiques, ou en utilisant le paramètre -o de la commande mount(8) pour les montages manuels.

Il faut noter qu’il existe un problème différent, que l’on confond parfois avec le précédent, qui peut se produire lorsque les serveurs et les clients NFS sont sur des réseaux différents. Si c’est le cas, assurez-vous que vos routeurs transmettent bien les informations UDP nécessaires, ou vous n’irez nulle part, quoi que vous fassiez par ailleurs.

Dans les exemples suivants, fastws est le nom de la station de travail (interface) performante, et freebox celui d’une machine (interface) FreeBSD avec une carte Ethernet moins performante. /sharedfs est le système de fichiers NFS qui sera exporté (consulter la page de manuel exports(5)), et /project sera le point de montage sur le client pour le système de fichiers exporté. Dans tous les cas, des options supplémentaires, telles que hard soft et bg seront peut-être nécessaires pour vos applications.

Exemple d’extrait du fichier /etc/fstab sur freebox quand le système FreeBSD (freebox) est le client:

Commande de montage manuelle sur freebox:

Exemple d’extrait du fichier /etc/fstab sur fastws quand le système FreeBSD est le serveur:

Commande de montage manuelle sur fastws:

Presque n’importe quelle carte Ethernet 16 bits permettra d’opérer sans l’utilisation des paramètres restrictifs précédents sur les tailles des tampons de lecture et d’écriture.

Pour ceux que cela intéresse, voici ce qui se passe quand le problème survient, ce qui explique également pourquoi ce n’est pas récupérable. NFS travaille généralement avec une taille de "bloc" de 8 k (bien qu’il arrive qu’il les fragmente en de plus petits morceaux). Comme la taille maximale d’un paquet Ethernet est de 1500 octets, le "bloc" NFS est divisé en plusieurs paquets Ethernet, bien qu’il soit toujours vu comme quelque chose d’unitaire par les couches supérieures du code, et doit être réceptionné, assemblé, et acquitté comme tel. Les stations de travail performantes peuvent traiter les paquets qui composent le bloc NFS les uns après les autres, pratiquement aussi rapidement que le standard le permet. Sur les cartes les plus petites, de moindre capacité, les derniers paquets d’un même bloc écrasent les paquets précédents avant qu’ils aient pu être transmis à la machine et le bloc ne peut être réassemblé ou acquitté. Avec pour conséquence, le dépassement du délai d’attente sur la station de travail qui recommence alors la transmission, mais en renvoyant l’intégralité des 8 K, et ce processus se répète à l’infini.

En définissant la taille de bloc inférieure à la taille d’un paquet Ethernet, nous nous assurons que chaque paquet Ethernet complet sera acquitté individuellement, évitant ainsi la situation de blocage.

Des écrasements peuvent toujours survenir quand des stations de travail performantes surchargent un système PC de données, mais avec de meilleures cartes, de tels écrasements ne sont pas systématiques pour les "blocs" NFS. Quand un écrasement apparaît, les blocs affectés sont retransmis, et ils y a de fortes chances pour qu’ils soient reçus, assemblés et acquittés.

NIS, qui signifie "Network Information Services" (services d’information réseau), fut développé par Sun Microsystems pour centraliser l’administration de systèmes UNIX® (à l’origine SunOS™). C’est devenu aujourd’hui un standard industriel; tous les systèmes importants de type UNIX® (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, etc.) supportent NIS.

NIS était appelé au départ "Yellow Pages" (page jaunes), mais étant donné que c’était marque déposée, Sun changea le nom. L’ancienne appelation (et yp) est toujours rencontrée et utilisée.

C’est un système client/serveur basé sur les RPCs qui permet à un groupe de machines d’un domaine NIS de partager un ensemble de fichiers de configuration communs. Cela permet à un administrateur système de mettre en place des clients NIS avec un minimum de configuration et d’ajouter, modifier ou supprimer les informations de configuration à partir d’un unique emplacement.

C’est similaire au système de domaine Windows NT®; bien que l’implémentation interne des deux n’est pas du tout identique, les fonctionnalités de base sont comparables.

Il existe plusieurs termes et processus utilisateurs que vous rencontrerez lors de la configuration de NIS sous FreeBSD, que vous vouliez mettre en place un serveur NIS ou un client NIS:

Dans un environnement NIS il y a trois types de machines: les serveurs maîtres, les serveurs esclaves et les clients. Les serveurs centralisent les informations de configuration des machines. Les serveurs maîtres détiennent l’exemplaire de référence de ces informations, tandis que les serveurs esclaves en ont un double pour assurer la redondance. Les clients attendent des serveurs qu’ils leur fournissent ces informations.

Le contenu de nombreux fichiers peut être partagé de cette manière. Les fichiers master.passwd, group, et hosts sont fréquemment partagés par l’intermédiaire de NIS. A chaque fois qu’un processus d’une machine cliente a besoin d’une information qu’il trouverait normalement localement dans un de ces fichiers, il émet une requête au serveur NIS auquel il est rattaché pour obtenir cette information.

Cette section traitera de la configuration d’un exemple d’environnement NIS.

De façon générale, n’importe quel utilisateur distant peut émettre une requête RPC à destination de ypserv(8) et récupérer le contenu de vos tables NIS, en supposant que l’utilisateur distant connaisse votre nom de domaine. Pour éviter ces transactions non autorisées, ypserv(8) dispose d’une fonctionnalité appelée "securenets" qui peut être utilisée pour restreindre l’accès à un ensemble donné de machines. Au démarrage, ypserv(8) tentera de charger les informations sur les "securenets" à partir d’un fichier nommé /var/yp/securenets.

Si ypserv(8) reçoit une requête d’une adresse qui satisfait à ces règles, il la traite normalement. Si une adresse ne correspond pas aux règles, la requête sera ignorée et un message d’avertissement sera enregistré. Si le fichier /var/yp/securenets n’existe pas, ypserv autorisera les connexions à partir de n’importe quelle machine.

Le programme ypserv supporte également l’outil TCP Wrapper de Wietse Venema. Cela permet à l’administrateur d’utiliser les fichiers de configuration de TCP Wrapper pour contrôler les accès à la place de /var/yp/securenets.

Dans notre laboratoire, il y a une machine basie qui est supposée être une station de travail de la faculté. Nous ne voulons pas retirer cette machine du domaine NIS, le fichier passwd sur le serveur maître NIS contient les comptes pour la faculté et les étudiants. Que pouvons-nous faire?

Il existe une méthode pour interdire à certains utilisateurs d’ouvrir une session sur une machine, même s’ils sont présents dans la base de données NIS. Pour cela, tout ce dont vous avez besoin de faire est d’ajouter -nom_utilisateur à la fin du fichier /etc/master.passwd sur la machine cliente, où nom_utilisateur est le nom de l’utilisateur auquel vous désirez refuser l’accès. Ceci doit être fait de préférence avec vipw, puisque vipw contrôlera vos changements au fichier /etc/master.passwd, et régénérera automatiquement la base de données à la fin de l’édition. Par exemple, si nous voulions interdire l’ouverture de session à l’utilisateur bill sur la machine basie nous ferions:

La méthode présentée dans la section précédente fonctionne relativement bien si vous avez besoin de règles spécifiques pour un petit nombre d’utilisateurs et/ou de machines. Sur les réseaux plus important, vous oublierez d’interdire l’accès aux machines sensibles à certains utilisateurs, ou vous devrez même modifier chaque machine séparément, perdant par là même les avantages du NIS: l’administration centralisée.

La solution des développeurs du NIS pour ce problème est appelé groupes réseau ("netgroups"). Leur objet et définition peuvent être comparés aux groupes utilisés par les systèmes UNIX®. La principale différence étant l’absence d’identifiants (ID) numériques et la capacité de définir un groupe réseau à l’aide de comptes utilisateur et d’autres groupes réseau.

Les groupes réseau furent développés pour gérer des réseaux importants et complexes avec des centaines de machines et d’utilisateurs. C’est une bonne option si vous êtes forcés de faire avec une telle situation. Cependant leur complexité rend impossible une explication avec des exemples simples. L’exemple utilisé dans le reste de cette section met en évidence ce problème.

Supposons que l’introduction avec succès de NIS dans votre laboratoire a retenu l’attention de vos supérieurs. Votre mission suivante est d’étendre la couverture de votre domaine NIS à d’autres machines sur le campus. Les deux tables contiennent les noms des nouveaux utilisateurs et des nouvelles machines ainsi qu’une courte description de chacun.

Si vous avez essayé d’implémenter ces restrictions en bloquant séparément chaque utilisateur, vous avez dû ajouter une ligne -utilisateur à chaque fichier passwd de chaque système pour chaque utilisateur non-autorisé à ouvrir une session sur le système. Si vous omettez ne serait-ce qu’une entrée, vous aurez des problèmes. Il doit être possible de faire cela lors de la configuration initiale, cependant vous finirez par oublier d’ajouter les lignes pour de nouveaux utilisateurs lors d’opérations quotidiennes. Après tout, Murphy était quelqu’un d’optimiste.

Traiter cette situation avec les groupes réseau présente plusieurs avantages. Chaque utilisateur n’a pas besoin d’être traité séparément; vous assignez un utilisateur à un ou plusieurs groupes réseau et autorisez ou refusez l’ouverture de session à tous les membres du groupe réseau. Si vous ajoutez une nouvelle machine, vous n’aurez à définir les restrictions d’ouverture de session que pour les groupes réseau. Ces modifications sont indépendantes les unes des autres, plus de "pour chaque combinaison d’utilisateur et de machine faire…​" Si votre configuration NIS est réfléchie, vous n’aurez à modifier qu’une configuration centrale pour autoriser ou refuser l’accès aux machines.

La première étape est l’initialisation de la table NIS du groupe réseau. La version FreeBSD d’ypinit(8) ne crée pas de table par défaut, mais son implémentation NIS la supportera une fois créée. Pour créer une table vide, tapez simplement

et commencez à ajouter du contenu. Pour notre exemple, nous avons besoin de quatre groupes réseau: les employées du département IT, les apprentis du département IT, les employés normaux et les internes.

IT_EMP, IT_APP etc. sont les noms des groupes réseau. Chaque groupement entre parenthèses ajoute un ou plusieurs comptes utilisateurs aux groupes. Les trois champs dans un groupement sont:

Chacun de ces champs peut contenir des jokers. Consultez la page de manuel netgroup(5) pour plus de détails.

Activer et propager votre nouvelle table NIS est simple:

Ceci générera les trois tables NIS netgroup, netgroup.byhost et netgroup.byuser. Utilisez ypcat(1) pour contrôler si vos nouvelles tables NIs sont disponibles:

La sortie devrait être semblable au contenu de /var/yp/netgroup. La deuxième commande ne produira pas de sortie si vous n’avez pas précisé les groupes réseau spécifiques à une machine. La troisième commande peut être utilisée pour obtenir les listes des groupes réseau pour un utilisateur.

La configuration du client est plutôt simple. Pour configurer le serveur war, vous devez lancer vipw(8) et remplacer la ligne

par

Maintenant, seules les données pour les utilisateurs définis dans le groupe réseau IT_EMP sont importées dans la base de données de mots de passe de war et seuls ces utilisateurs sont autorisés à ouvrir une session.

Malheureusement, cette limitation s’applique également à la fonction ~ de l’interpréteur de commandes et toutes les routines de conversion entre nom d’utilisateur et identifiant numérique d’utilisateur. En d’autres termes, cd ~utilisateur ne fonctionnera pas, et ls -l affichera l’ID numérique à la place du nom d’utilisateur et find . -user joe -print échouera avec le message d’erreur No such user. Pour corriger cela, vous devrez importer toutes les entrées d’utilisateurs sans leur autoriser l’ouverture de session sur vos serveurs.

Cela peut être fait en ajoutant une autre ligne au fichier /etc/master.passwd. Cette ligne devrait contenir:

+:::::::::/sbin/nologin, signifiant "Importer toutes les entrées mais remplacer l’interpréteur de commandes avec /sbin/nologin dans les entrées importées". Vous pouvez remplacer n’importe quel champ dans l’entrée passwd en plaçant une valeur par défaut dans votre fichier /etc/master.passwd.

Après cette modification, vous ne devrez uniquement que modifier une des tables NIS si un nouvel employé rejoint le département IT. Vous pourrez utiliser une approche similaire pour les serveurs moins importants en remplaçant l’ancienne ligne +::::::::: dans leur version locale de /etc/master.passwd avec quelque chose de semblable à ceci:

Les lignes correspondantes pour les stations de travail normales seraient:

Tout était parfait jusqu’au changement de politique quelques semaines plus tard: le département IT commença à engager des internes. Les internes du département IT sont autorisés à utiliser les stations de travail normales et les serveurs les moins importants; les apprentis du département IT sont autorisés à ouvrir des sessions sur les serveurs principaux. Vous ajoutez alors un nouveau groupe réseau IT_INTERN, ajoutez les nouveaux internes IT à ce groupe réseau et commencez à modifier la configuration sur chaque machine…​ Comme disait l’ancien: "Erreurs dans la planification centralisée mènent à un désordre général".

La capacité de NIS à créer des groupes réseau à partir d’autres groupes réseau peut être utilisée pour éviter de telles situations. Une possibilité est la création de groupes réseau basés sur le rôle du groupe. Par exemple vous pourriez créer un groupe réseau appelé BIGSRV pour définir les restrictions d’ouverture de session pour les serveurs importants, un autre groupe réseau appelé SMALLSRV pour les serveurs moins importants et un troisième groupe réseau nommé USERBOX pour les stations de travail normales. Chacun de ces groupes réseau contient les groupes réseau autorisés à ouvrir des sessions sur ces machines. Les nouvelles entrées pour la table NIS de groupes réseau devrait ressembler à ceci:

Cette méthode qui consiste à définir des restrictions d’ouverture de session fonctionne relativement bien si vous pouvez définir des groupes de machines avec des restrictions identiques. Malheureusement, ceci est une exception et pas une généralité. La plupart du temps, vous aurez besoin de définir des restrictions d’ouverture de session par machine.

La définition de groupes réseau spécifiques aux machines est une autre possibilité pour traiter la modification de politique soulignée précédemment. Dans ce scénario, le fichier /etc/master.passwd de chaque machine contient deux lignes débutant par "+". La première ajoute un groupe réseau avec les comptes autorisés à ouvrir une session sur cette machine, la seconde ajoute tous les comptes avec l’interpréteur de commandes /sbin/nologin. C’est une bonne idée d’utiliser des majuscules pour le nom de la machine ainsi que celui du groupe réseau. Dans d’autres termes, les lignes en question devraient être semblables à:

Une fois cette tâche achevée pour toutes vos machines, vous n’aurez plus jamais à modifier les versions locales du fichier /etc/master.passwd. Tous les changements futurs peuvent être gérés en modifiant la table NIS. Voici un exemple d’une table de groupes réseau possible pour ce scénario avec quelques petits plus:

Si vous utilisez une sorte de base de données pour gérer vos comptes utilisateur, vous devriez pouvoir créer la première partie de la table avec les outils de votre base de données. De cette façon, les nouveaux utilisateurs auront automatiquement accès aux machines.

Dernier avertissement: il n’est pas toujours conseillé d’utiliser des groupes réseau basés sur les machines. Si vous déployez quelques douzaines ou même centaines de machines identiques pour des laboratoires pour étudiants, vous devriez utiliser des groupes basés sur les types d’utilisateurs plutôt que sur les machines pour conserver la taille de la table NIS dans des limites raisonnables.

Il y a un certain nombre de choses que vous devrez effectuer différemment maintenant que vous êtes dans un environnement NIS.

ypserv sous FreeBSD offre un support des clients NIS version 1. L’implémentation NIS de FreeBSD utilise uniquement le protocole NIS version 2, cependant d’autres implémentations disposent du support pour le protocole version 1 pour des raisons de compatibilité avec d’anciens systèmes. Les "daemons" ypbind fournis avec ces systèmes tenteront de s’attacher à un serveur NIS version 1 même s’ils n’en ont pas besoin (et ils pourront continuer à diffuser des requêtes pour en trouver un même après avoir reçu une réponse d’un serveur NIS version 2). Notez que bien que les requêtes des clients normaux soient supportées, cette version d’ypserv ne supporte pas les requêtes de transfert de tables version 1; par conséquent il n’est pas possible de l’utiliser comme serveur maître ou esclave avec des serveurs NIS plus anciens qui ne supportent que la version 1 du protocole. Heureusement, il n’y a, aujourd’hui, presque plus de serveurs de ce type actifs.

Il faut faire attention quand on utilise ypserv dans un domaine avec plusieurs serveurs NIS qui sont également des clients NIS. Il est en général préférable de forcer les serveurs de se rattacher à eux-mêmes plutôt que de les laisser diffuser des requêtes de rattachement et éventuellement se rattacher réciproquement les uns aux autres. Il peut en résulter de curieux problèmes si l’un des serveurs tombe et que d’autres en dépendent. Tous les clients finiront par dépasser leur délai d’attente et se tenteront de se rattacher à d’autres serveurs, mais ce délai peut être considérable et le problème persistera puisque les serveurs peuvent à nouveau se rattacher les uns aux autres.

Vous pouvez obliger une machine à se rattacher à un serveur particulier en exécutant ypbind avec l’option -S. Si vous ne désirez pas faire cela à la main à chaque fois que vous redémarrez votre serveur NIS, vous pouvez ajouter les lignes suivantes à votre fichier /etc/rc.conf:

Voir la page de manuel de ypbind(8) pour plus d’informations.

Un des problèmes les plus courants que l’on rencontre en mettant en oeuvre NIS est celui de la compatibilité des formats de mots de passe. Si votre serveur NIS utilise des mots de passe chiffrés avec l’algorithme DES, il ne supportera que les clients utilisant également DES. Par exemple, si vous avez des client NIS Solaris™ sur votre réseau, alors vous aurez presque certainement besoin d’utiliser des mots de passe chiffrés avec le système DES.

Pour déterminer quel format vos serveurs et clients utilisent, consultez le fichier /etc/login.conf. Si la machine est configurée pour utiliser des mots de passe chiffrés avec DES, alors la classe default contiendra une entrée comme celle-ci:

D’autres valeurs possibles pour la capacité passwd_format sont blf et md5 (respectivement pour les chiffrages de mots de passe Blowfish et MD5).

Si vous avez modifié le fichier /etc/login.conf, vous devrez également regénérer la base de données des capacités de classes de session, ce qui est accompli en exécutant la commande suivante en tant que root:

Ensuite, afin de s’assurer que les mots de passe sont chiffrés avec le format que vous avez choisi, vous devez vérifier que l’entrée crypt_default dans le fichier /etc/auth.conf donne la priorité au format de mots de passe choisi. Par exemple, quand les mots de passe DES sont utilisés, l’entrée serait:

En suivant les points précédents sur chaque serveur et client NIS sous FreeBSD, vous pouvez être sûr qu’ils seront tous d’accord sur le format de mot de passe utilisé dans le réseau. Si vous avez des problèmes d’authentification sur un client NIS, c’est probablement la première chose à vérifier. Rappelez-vous: si vous désirez mettre en place un serveur NIS pour un réseau hétérogène, vous devrez probablement utiliser DES sur tous les systèmes car c’est le standard le plus courant.

DHCP, le protocole d’attribution dynamique des adresses ("Dynamic Host Configuration Protocol"), décrit les moyens par lesquels un système peut se connecter à un réseau et obtenir les informations nécessaires pour dialoguer sur ce réseau. Les versions de FreeBSD antérieures à la version 6.0 utilisent l’implémentation du client DHCP (dhclient(8)) de l’ISC (Internet Software Consortium). Les versions suivantes utilisent le programme dhclient d’OpenBSD issu d’OpenBSD 3.7. Toutes les informations données ici au sujet de dhclient sont valables aussi bien pour le client DHCP d’ISC que pour celui d’OpenBSD. Le serveur DHCP est celui distribué par le consortium ISC.

Cette section décrit les composants côté client des clients DHCP d’ISC et d' OpenBSD et côté serveur du système DHCP ISC. Le programme client, dhclient, est intégré à FreeBSD, la partie serveur est disponible à partir du logiciel porté net/isc-dhcp3-server. Les pages de manuel dhclient(8), dhcp-options(5), et dhclient.conf(5), en plus des références données plus bas, sont des ressources utiles.

Quand dhclient, le client DHCP, est exécuté sur la machine cliente, il commence à diffuser des requêtes de demandes d’information de configuration. Par défaut, ces requêtes sont effectuées sur le port UDP 68. Le serveur répond sur le port UDP 67, fournissant au client une adresse IP et d’autres informations réseau importantes comme le masque de sous-réseau, les routeurs, et les serveurs DNS. Toutes ces informations viennent sous la forme d’un "bail" DHCP qui est uniquement valide pendant un certain temps (configuré par l’administrateur du serveur DHCP). De cette façon, les adresses IP expirées pour les clients qui ne sont plus connectés peuvent être automatiquement récupérées.

Les clients DHCP peuvent obtenir une grande quantité d’informations à partir du serveur. Une liste exhaustive est donnée dans la page de manuel dhcp-options(5).

Le client DHCP ISC ou OpenBSD (en fonction de la version de FreeBSD que vous utilisez), dhclient, est complètement intégré à FreeBSD. Le support du client DHCP est fourni avec l’installeur et le système de base, rendant évident le besoin d’une connaissance détaillée des configurations réseaux pour n’importe quel réseau utilisant un serveur DHCP. dhclient fait partie de toutes les versions de FreeBSD depuis la version 3.2.

DHCP est supporté par sysinstall. Quand on configure une interface réseau sous sysinstall, la deuxième question posée est: "Voulez-vous tenter la configuration DHCP de l’interface?". Répondre par l’affirmative à cette question lancera dhclient, et en cas de succès, complétera automatiquement les informations de configuration réseau.

Vous devez faire deux choses pour que votre système utilise DHCP au démarrage:

Le serveur DHCP, dhcpd, fait partie du logiciel porté net/isc-dhcp3-server disponible dans le catalogue des logiciels portés. Ce logiciel porté contient le serveur DHCP ISC et sa documentation.

Le protocole DHCP est intégralement décrit dans la RFC 2131. Des informations sont également disponibles à l’adresse http://www.dhcp.org/.

FreeBSD utilise, par défaut, BIND (Berkeley Internet Name Domain), qui est l’implémentation la plus courante du protocole DNS. Le DNS est le protocole qui effectue la correspondance entre noms et adresses IP, et inversement. Par exemple une requête pour www.FreeBSD.org aura pour réponse l’adresse IP du serveur Web du projet FreeBSD, et une requête pour ftp.FreeBSD.org renverra l’adresse IP de la machine FTP correspondante. De même, l’opposé est possible. Une requête pour une adresse IP retourne son nom de machine. Il n’est pas nécessaire de faire tourner un serveur DNS pour effectuer des requêtes DNS sur un système.

FreeBSD est actuellement fourni par défaut avec le serveur DNSBIND9. Notre installation est dotée de fonctionnalités étendues au niveau de la sécurité, d’une nouvelle organisation du système de fichiers et d’une configuration en environnement chroot(8) automatisée.

Le DNS est coordonné sur l’Internet à travers un système complexe de serveurs de noms racines faisant autorité, de domaines de premier niveau ("Top Level Domain", TLD), et d’autres serveurs de noms de plus petites tailles qui hébergent, directement ou font office de "cache", l’information pour des domaines individuels.

Actuellement, BIND est maintenu par l’Internet Software Consortium http://www.isc.org/.

Pour comprendre ce document, certains termes relatifs au DNS doivent être maîtrisés.

Exemples de zones:

Comme on peut le remarquer, la partie la plus significative d’un nom de machine est à sa gauche. Par exemple, example.org. est plus spécifique que org., comme org. est à son tour plus spécifique que la zone racine. La constitution de chaque partie d’un nom de machine est proche de celle d’un système de fichiers: le répertoire /dev se trouve sous la racine, et ainsi de suite.

Les serveurs de noms se présentent généralement sous deux formes: un serveur de noms faisant autorité, et un serveur de noms cache.

Un serveur de noms faisant autorité est nécessaire quand:

Un serveur de noms cache est nécessaire quand:

Quand on émet des requêtes pour www.FreeBSD.org, le résolveur interroge généralement le serveur de noms du fournisseur d’accès, et récupère la réponse. Avec un serveur DNS cache local, la requête doit être effectuée qu’une seule fois vers le monde extérieur par le serveur DNS cache. Chaque interrogation suivante n’aura pas à être transmise en dehors du réseau local, puisque l’information est désormais disponible localement dans le cache.

Sous FreeBSD le "daemon" BIND est appelé named pour des raisons évidentes.

En fonction de la manière dont est configurée sur le serveur une zone donnée, les fichiers relatifs à cette zone pourront être trouvés dans les sous-répertoires master, slave, ou dynamic du répertoire /etc/namedb. Ces fichiers contiennent les informations DNS qui seront données par le serveur de noms en réponse aux requêtes.

Puisque BIND est installé par défaut, sa configuration est relativement simple.

La configuration par défaut de named est un serveur de noms résolveur basique, tournant dans un environnement chroot(8). Pour lancer le serveur avec cette configuration, utilisez la commande suivante:

Pour s’assurer que le "daemon" named est lancé à chaque démarrage, ajoutez la ligne suivante dans /etc/rc.conf:

Il existe, bien évidemment, de nombreuses options de configuration pour /etc/namedb/named.conf qui dépassent le cadre de ce document. Si vous êtes intéressé par les options de démarrage de named sous FreeBSD, jetez un oeil aux paramètres named_* dans /etc/defaults/rc.conf et consultez la page de manuel rc.conf(5). La section Utilisation du système rc(8) sous FreeBSD constitue également une bonne lecture.

Les fichiers de configuration pour named se trouvent dans le répertoire /etc/namedb et devront être adaptés avant toute utilisation, à moins que l’on ait besoin que d’un simple résolveur. C’est dans ce répertoire où la majeure partie de la configuration se fera.

Un serveur de noms cache est un serveur de noms qui ne fait autorité pour aucune zone. Il émet simplement des requêtes, et se souvient du résultat pour une utilisation ultérieure. Pour mettre en place un tel serveur, configurez le serveur de noms comme à l’accoutumé, en prenant bien soin de n’inclure aucune zone.

Bien que BIND soit l’implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert.

Bien que FreeBSD enferme automatiquement named dans un environnement chroot(8), il existe plusieurs autres mécanismes de sécurité qui pourraient aider à se prémunir contre de possibles attaques DNS.

C’est une bonne idée de lire les avis de sécurité du CERT et de s’inscrire à la liste de diffusion des avis de sécurité pour FreeBSD pour se maintenir au courant des problèmes de sécurité actuels de l’Internet et de FreeBSD.

Les pages de manuel de BIND/named: rndc(8) named(8) named.conf(8).

FreeBSD est utilisé pour faire tourner certains des sites les plus chargés au monde. La majorité des serveurs web sur l’Internet utilisent le serveur HTTP Apache. Les versions pré-compilées d’Apache devraient se trouver sur le support d’installation de FreeBSD que vous avez utilisé. Si vous n’avez pas installé Apache à l’installation de FreeBSD, alors vous pouvez installer le serveur à partir du logiciel porté www/apache13 ou www/apache20.

Une fois qu’Apache a été installé avec succès, il doit être configuré.

Le fichier principal de configuration du serveur HTTP Apache est, sous FreeBSD, le fichier /usr/local/etc/apache/httpd.conf. Ce fichier est un fichier texte de configuration UNIX® typique avec des lignes de commentaires débutant par un caractère #. Une description complète de toutes les options de configuration possibles dépasse le cadre de cet ouvrage, aussi seules les directives les plus fréquemment modifiées seront décrites ici.

C’est toujours une bonne idée de faire des copies de sauvegarde de votre fichier de configuration d’Apache avant de faire des modifications. Une fois que vous êtes satisfait avec votre configuration, vous êtes prêt à lancer Apache.

Apache n’est pas lancé à partir du "super-serveur" inetd comme pour beaucoup d’autres serveurs réseau. Il est configuré pour tourner de façon autonome pour de meilleures performances à la réception des requêtes HTTP des navigateurs web. Une procédure est fournie pour rendre le démarrage, l’arrêt, et le redémarrage du serveur aussi simple que possible. Pour démarrer Apache pour la première fois, exécutez:

Vous pouvez arrêter le serveur à tout moment en tapant:

Après avoir effectué des modifications dans le fichier de configuration, vous devez redémarrer le serveur:

Pour redémarrer Apache sans faire échouer les connexions en cours, exécutez:

Des informations supplémentaires sont disponibles dans la page de manuel d’apachectl(8).

Pour lancer Apache au démarrage du système, ajoutez la ligne suivante au fichier /etc/rc.conf:

Si vous désirez passer des options en ligne de commande supplémentaires au programme httpd d’Apache lancé au démarrage du système, vous pouvez les spécifier à l’aide d’une ligne dans rc.conf:

Maintenant que le serveur web tourne, vous pouvez voir votre site web en pointant votre navigateur sur http://localhost/. La page web affichée par défaut est /usr/local/www/data/index.html.

Apache supporte deux types différents de serveurs virtuels. Le premier type est celui des serveurs virtuels basés sur les noms. Ce type de serveurs virtuels utilise les entêtes HTTP/1.1 pour déterminer le nom de la machine. Cela autorise le partage de la même adresse IP entre plusieurs domaines différents.

Pour configurer Apache à l’utilisation de serveurs virtuels basés sur les noms, ajoutez une entrée comme la suivante à votre fichier httpd.conf:

Si votre serveur web est appelé www.domain.tld et que vous voulez mettre en place un domain virtuel pour www.someotherdomain.tld alors vous ajouterez les entrées suivantes au fichier httpd.conf:

Remplacez les addresses avec celles que vous désirez utiliser et le chemin d’accès des documents avec celui que vous utilisez.

Pour plus d’informations sur la mise en place de serveurs virtuels, veuillez consulter la documentation officielle d’Apache à l’adresse http://httpd.apache.org/docs/vhosts/.

Il existe de nombreux modules Apache disponibles en vue d’ajouter des fonctionnalités au serveur de base. Le catalogue des logiciels portés offre une méthode simple d’installation d’Apache avec certains des modules les plus populaires.

Le protocol de transfert de fichiers (FTP) offre aux utilisateurs une méthode simple pour transférer des fichiers vers ou à partir d’un serveur FTP. FreeBSD comprend un serveur FTP, ftpd, dans le système de base. Cela rend la configuration et l’administration d’un serveur FTP sous FreeBSD très simple.

L’étape de configuration la plus important est de décider quels comptes seront autorisés à accéder au serveur FTP. Un système FreeBSD classique possède de nombreux comptes système utilisés par divers "daemon"s, mais les utilisateurs inconnus ne devraient pas être autorisés à ouvrir de session sous ces comptes. Le fichier /etc/ftpusers est une liste d’utilisateurs interdits d’accès au serveur FTP. Par défaut, il inclut les comptes systèmes précédemment mentionnés, mais il est possible d’ajouter des utilisateurs précis qui ne devraient pas avoir accès au serveur FTP.

Vous pouvez vouloir restreindre l’accès à certains utilisateurs sans leur refuser complètement l’utilisation du serveur FTP. Cela peut être réalisé à l’aide du fichier /etc/ftpchroot. Ce fichier liste les utilisateurs et les groupes sujet à des restrictions d’accès FTP. La page de manuel ftpchroot(5) fournit tous les détails, cela ne sera donc pas décrit ici.

Si vous désirez activer l’accès FTP anonyme sur votre serveur, vous devez alors créer un utilisateur appelé ftp sur votre serveur FreeBSD. Les utilisateurs seront donc en mesure d’ouvrir une session FTP sur votre serveur sous le nom d’utilisateur ftp ou anonymous et sans aucun mot de passe (par convention l’adresse électronique de l’utilisateur devrait être utilisée comme mot de passe). Le serveur FTP appellera chroot(2) quand un utilisateur anonyme ouvrira une session, pour restreindre l’accès juste au répertoire personnel de l’utilisateur ftp.

Il existe deux fichiers texte qui spécifient les messages de bienvenue à afficher aux clients FTP. Le contenu du fichier /etc/ftpwelcome sera affiché aux utilisateurs avant qu’ils atteignent l’invite de session. Après une ouverture de session, le contenu du fichier /etc/ftpmotd sera affiché. Notez que le chemin d’accès à ce fichier est relatif à l’environnement de la session, aussi le fichier ~ftp/etc/ftpmotd sera affiché aux utilisateurs anonymes.

Une fois que le serveur FTP a été configuré correctement, il doit être activé dans le fichier /etc/inetd.conf. Ici il faut juste retirer le symbole de commentaire "#" en face de la ligne ftpd:

Comme expliqué dans la Recharger le fichier de configuration d’inetd, la configuration d’inetd doit être rechargée après que le fichier de configuration ait été modifié.

Vous pouvez maintenant ouvrir une session FTP sur votre serveur en tapant:

Le "daemon" ftpd utilise syslog(3) pour l’enregistrement des messages. Par défaut, le "daemon" de gestion des journaux du système enverra les messages relatifs au FTP dans le fichier /var/log/xferlog. L’emplacement des journaux FTP peut être modifié en changeant la ligne suivante dans le fichier /etc/syslog.conf:

Soyez conscient des éventuels problèmes impliqués par l’utilisation d’un serveur FTP acceptant les connexions anonymes. Vous devriez, tout particulièrement, penser à deux fois avant d’autoriser les utilisateurs anonyme à déposer des fichiers sur le serveur. Votre site FTP pourrait devenir un forum d’échange de logiciels commerciaux sans les licences ou pire. Si vous devez autoriser le dépôt de fichiers de façon anonyme sur le serveur FTP, alors vous devriez fixer les permissions sur ces fichiers de telle sorte qu’ils ne puissent être lus par d’autres utilisateurs anonymes avant qu’ils n’aient pu être contrôlés.

Samba est un logiciel libre très populaire qui offre des services de partage de fichiers et d’imprimantes pour les clients Microsoft® Windows®. De tels clients peuvent se connecter et utiliser l’espace de fichiers d’une machine FreeBSD comme si c’était un disque local, ou utiliser des imprimantes FreeBSD comme si elles étaient des imprimantes locales.

Samba devrait se trouver sur votre support d’installation. Si vous n’avez pas installé Samba à l’installation de FreeBSD, vous pouvez alors l’installer à partir de la version pré-compilée ou portée net/samba3.

Le fichier de configuration par défaut de Samba est installé sous le nom /usr/local/etc/smb.conf.default. Ce fichier doit être copié vers /usr/local/etc/smb.conf et personnalisé avant que Samba ne puisse être utilisé.

Le fichier smb.conf contient la configuration nécessaire à l’exécution de Samba, comme la définition des imprimantes et des "systèmes de fichiers partagés" que vous désirez partager avec les clients Windows®. Le logiciel Samba comprend une interface Web appelé swat qui offre une méthode simple de configuration du fichier smb.conf.

Le logiciel porté net/samba3 amène une nouvelle procédure de démarrage qui peut être employée pour contrôler Samba. Pour activer cette procédure de manière à ce qu’elle soit utilisée pour par exemple lancer, arrêter ou relancer Samba, ajoutez la ligne suivante au fichier /etc/rc.conf:

Ou, pour un contrôle plus fin:

Il est alors possible de démarrer Samba à n’importe quel moment en tapant:

Veuillez consulter la Utilisation du système rc(8) sous FreeBSD pour plus d’information sur les procédures rc.

Samba consiste essentiellement en trois "daemon"s séparés. Vous devriez vous rendre compte que les "daemon"s nmbd et smbd sont lancés par la procédure samba. Si vous avez activé la résolution de noms winbind dans le fichier smb.conf, alors le "daemon" winbindd sera également lancé.

Vous pouvez arrêter Samba à tout moment en tapant:

Samba est une suite logiciels complexes avec des fonctionnalités permettant une large intégration avec les réseaux Microsoft® Windows®. Pour plus d’information sur les fonctionnalités non-abordées dans ce document, veuillez consulter http://www.samba.org.

Avec le temps, l’horloge d’un ordinateur tend à dériver. Le protocole NTP ("Network Time Protocol") est une des manières pour s’assurer que votre horloge reste précise.

De nombreux services Internet ont besoin, ou tirent partie, de la précision des horloges des ordinateurs. Par exemple, un serveur web, peut recevoir des requêtes pour n’envoyer un fichier que s’il a été modifié depuis un certain temps. Sur un réseau local, il est essentiel que les ordinateurs partageant des fichiers à partir du même serveur de fichiers aient des horloges synchronisées de manière à ce que les dates de création ou de dernière modification d’un fichier ("timestamp") soient cohérentes. Des services comme cron(8) reposent sur une horloge système précise pour exécuter des commandes à des moments précis.

FreeBSD est fourni avec le serveur NTP ntpd(8) qui peut être utilisé pour contacter d’autres serveurs NTP pour régler l’horloge de votre machine ou pour jouer le rôle de serveur de temps pour d’autres.

Afin de synchroniser votre horloge, vous devrez trouver un ou plusieurs serveurs NTP. Votre administrateur réseau ou votre FAI peuvent avoir mis en place un serveur NTP dans cet objectif-consultez leur documentation pour voir si c’est le cas. Il existe une liste en ligne de serveurs NTP accessibles par le public que vous pouvez utiliser pour trouver un serveur NTP proche de vous. Assurez-vous d’avoir pris connaissance de la politique d’utilisation des serveurs que vous choisissez, et demandez la permission si nécessaire.

Choisir plusieurs serveurs NTP non-connectés entre eux est une bonne idée au cas où un des serveurs que vous utilisez devient inaccessible ou que son horloge n’est plus fiable. ntpd(8) utilise intelligemment les réponses qu’il reçoit d’autres serveurs-il favorisera les plus fiables par rapport aux moins fiables.

Pour s’assurer que le serveur NTP est lancé au démarrage, ajoutez la ligne ntpd_enable="YES" dans le fichier /etc/rc.conf. Si vous désirez passer des indicateurs supplémentaires à ntpd(8), éditez les paramètres de l’option ntpd_flags dans /etc/rc.conf.

Pour lancer le serveur sans redémarrer votre machine, exécutez ntpd en étant sûr de préciser tout paramètre supplémentaire de ntpd_flags dans /etc/rc.conf. Par exemple:

Le programme ntpd(8) n’a pas besoin d’une connexion permanente à l’Internet pour fonctionner correctement. Cependant, si vous disposez d’une connexion temporaire qui est configurée de telle sorte qu’il y ait établissement de la connexion à la demande, c’est une bonne idée d’empêcher le trafic NTP de déclencher la numérotation ou de maintenir constamment établie la connexion. Si vous utilisez PPP en mode utilisateur, vous pouvez employer les directives filter dans le fichier /etc/ppp/ppp.conf. Par exemple:

Pour plus de détails lisez la section PACKET FILTERING de la page de manuel ppp(8) et les exemples du répertoire /usr/shared/examples/ppp/.

La documentation pour le serveur NTP peut être trouvée dans le répertoire /usr/shared/doc/ntp/ sous le format HTML.