Administration de systèmes UNIX Formation ARS

Transcription

1 Administration de systèmes UNIX Formation ARS Partie 3 Thierry Besançon Formation Permanente de l Université Pierre et Marie Curie c T.Besançon (v ) Administration UNIX ARS Partie 3 1 / 789

2 Chapitre 1 Ethernet c T.Besançon (v ) Administration UNIX ARS Partie 3 2 / Ethernet 1.1 Principe d Ethernet : CSMA/CD Chapitre 1 Ethernet 1.1 Principe d Ethernet : CSMA/CD Le principe d Ethernet : Carrier Sence Multiple Access / Collision Detect (CSMA/CD) 2 cas de figure : 1 Emission dans le cas du câble libre 2 Emission lorsque deux stations émettent simultanément = collision c T.Besançon (v ) Administration UNIX ARS Partie 3 3 / 789

3 1 Ethernet 1.1 Principe d Ethernet : CSMA/CD Emission dans le cas du câble libre c T.Besançon (v ) Administration UNIX ARS Partie 3 4 / Ethernet 1.1 Principe d Ethernet : CSMA/CD Collision lorsque deux stations émettent simultanément c T.Besançon (v ) Administration UNIX ARS Partie 3 5 / 789

4 1 Ethernet 1.2 Ethernet 10 Base 5 Chapitre 1 Ethernet 1.2 Ethernet 10 Base 5 Cablage obsolète " #! c T.Besançon (v ) Administration UNIX ARS Partie 3 6 / Ethernet 1.2 Ethernet 10 Base 5 DTE DTE DTE c T.Besançon (v ) Administration UNIX ARS Partie 3 7 / 789

5 1 Ethernet 1.2 Ethernet 10 Base 5 Un ensemble monté c T.Besançon (v ) Administration UNIX ARS Partie 3 8 / Ethernet 1.2 Ethernet 10 Base 5 Une prise vampire démontée c T.Besançon (v ) Administration UNIX ARS Partie 3 9 / 789

6 1 Ethernet 1.2 Ethernet 10 Base 5 Le cable AUI, une prise vampire et son transceiver c T.Besançon (v ) Administration UNIX ARS Partie 3 10 / Ethernet 1.2 Ethernet 10 Base 5 Connecteurs 10 Base 5 sur un mini-transceiver et un drop cable c T.Besançon (v ) Administration UNIX ARS Partie 3 11 / 789

7 1 Ethernet 1.2 Ethernet 10 Base 5 Carte combo 10Base5 et 10BaseT c T.Besançon (v ) Administration UNIX ARS Partie 3 12 / Ethernet 1.2 Ethernet 10 Base 5 Mini transceiver low profile 10Base5 - RJ45 c T.Besançon (v ) Administration UNIX ARS Partie 3 13 / 789

8 "! 1 Ethernet 1.2 Ethernet 10 Base 5 Mini transceiver low profile 10Base5 - RJ45 au dos d une machine c T.Besançon (v ) Administration UNIX ARS Partie 3 14 / Ethernet 1.3 Ethernet 10 Base 2 Chapitre 1 Ethernet 1.3 Ethernet 10 Base 2 Cablage obsolète # Male BNC 50 Ohm c T.Besançon (v ) Administration UNIX ARS Partie 3 15 / 789

9 1 Ethernet 1.3 Ethernet 10 Base 2 DTE DTE DTE DTE c T.Besançon (v ) Administration UNIX ARS Partie 3 16 / Ethernet 1.3 Ethernet 10 Base 2 c T.Besançon (v ) Administration UNIX ARS Partie 3 17 / 789

10 1 Ethernet 1.3 Ethernet 10 Base 2 Sertissage d une prise 10Base2 c T.Besançon (v ) Administration UNIX ARS Partie 3 18 / Ethernet 1.3 Ethernet 10 Base 2 c T.Besançon (v ) Administration UNIX ARS Partie 3 19 / 789

11 1 Ethernet 1.3 Ethernet 10 Base 2 c T.Besançon (v ) Administration UNIX ARS Partie 3 20 / Ethernet 1.3 Ethernet 10 Base 2 La prise sertie c T.Besançon (v ) Administration UNIX ARS Partie 3 21 / 789

12 1 Ethernet 1.3 Ethernet 10 Base 2 Raccordement : té 10Base2 c T.Besançon (v ) Administration UNIX ARS Partie 3 22 / Ethernet 1.3 Ethernet 10 Base 2 c T.Besançon (v ) Administration UNIX ARS Partie 3 23 / 789

13 1 Ethernet 1.3 Ethernet 10 Base 2 En fin de cable : terminateur 50 Ohms 10Base2 c T.Besançon (v ) Administration UNIX ARS Partie 3 24 / Ethernet 1.3 Ethernet 10 Base 2 Carte combo 10Base2 et 10BaseT c T.Besançon (v ) Administration UNIX ARS Partie 3 25 / 789

14 % 1 Ethernet 1.4 Ethernet 10 Base T, 100 Base T Chapitre 1 Ethernet 1.4 Ethernet 10 Base T, 100 Base T 10 Base T = Cablage obsolète % % % * & & & ' ( ) +, ) BNC!! "!! 2 3 & # $ ) & # 4 + ' ( 5 3 ) & & + ' ( +, ) & - &!,. & / - &!, & 0 -,. & 1 -, c T.Besançon (v ) Administration UNIX ARS Partie 3 26 / Ethernet 1.4 Ethernet 10 Base T, 100 Base T H U B c T.Besançon (v ) Administration UNIX ARS Partie 3 27 / 789

15 1 Ethernet 1.4 Ethernet 10 Base T, 100 Base T Prise à sertir c T.Besançon (v ) Administration UNIX ARS Partie 3 28 / Ethernet 1.4 Ethernet 10 Base T, 100 Base T Cable croisé pour relier deux ordinateurs entre eux ou deux switches c T.Besançon (v ) Administration UNIX ARS Partie 3 29 / 789

16 1 Ethernet 1.4 Ethernet 10 Base T, 100 Base T c T.Besançon (v ) Administration UNIX ARS Partie 3 30 / Ethernet 1.5 Format d une adresse Ethernet Chapitre 1 Ethernet 1.5 Format d une adresse Ethernet Format d une adresse Ethernet : 6 octets écrits sous la forme hexadécimale «xx:yy:zz:rr:ss:tt» avec : partie «xx:yy:zz» : elle identifie un constructeur partie «rr:ss:tt» : elle identifie un appareil chez le constructeur Liste des constructeurs : liste des OUI (Organizationally Unique Identifiers) : « c T.Besançon (v ) Administration UNIX ARS Partie 3 31 / 789

17 1 Ethernet 1.5 Format d une adresse Ethernet Il existe une adresse de broadcast Ethernet : «ff:ff:ff:ff:ff:ff» Toutes les machines du segment Ethernet sont censées écouter le paquet. c T.Besançon (v ) Administration UNIX ARS Partie 3 32 / Ethernet 1.6 Trouver son adresse Ethernet sur UNIX/LINUX Chapitre 1 Ethernet 1.6 Trouver son adresse Ethernet sur UNIX/LINUX Pour trouver son adresse Ethernet sur UNIX/LINUX : plusieurs méthodes : 1 repérer les périphériques dans la sortie de «dmesg» au moment du boot 2 utiliser la commande de configuration des interfaces pour visualiser les adresses Ethernet c T.Besançon (v ) Administration UNIX ARS Partie 3 33 / 789

18 1 Ethernet 1.6 Trouver son adresse Ethernet sur UNIX/LINUX Méthode via «dmesg» # dmesg... Intel(R) PRO/1000 Network Driver - version k2-NAPI Copyright (c) Intel Corporation. e1000: 0000:02:01.0: e1000_probe: (PCI-X:66MHz:64-bit) 00:11:09:5a:f0:d8 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection... e1000: 0000:02:01.1: e1000_probe: (PCI-X:66MHz:64-bit) 00:11:09:5a:f0:d9 e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection... Attention à ne pas attendre trop longtemps pour ne pas perdre le contenu de «dmesg». c T.Besançon (v ) Administration UNIX ARS Partie 3 34 / Ethernet 1.6 Trouver son adresse Ethernet sur UNIX/LINUX Méthode via «ifconfig» # ifconfig -a eth0 Link encap:ethernet HWaddr 00:11:09:5A:F0:D8 inet addr: Bcast: Mask: inet6 addr: fe80::211:9ff:fe5a:f0d8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes: (2.6 GiB) TX bytes: (3.3 GiB) Base address:0x2000 Memory:d d eth1 Link encap:ethernet HWaddr 00:11:09:5A:F0:D9 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Base address:0x2040 Memory:d d C est la méthode la plus universelle. c T.Besançon (v ) Administration UNIX ARS Partie 3 35 / 789

19 1 Ethernet 1.7 Trouver son adresse Ethernet sur WINDOWS Chapitre 1 Ethernet 1.7 Trouver son adresse Ethernet sur WINDOWS Commande «getmac.exe» à partir de MICROSOFT Windows XP. c T.Besançon (v ) Administration UNIX ARS Partie 3 36 / Ethernet 1.8 Format d une trame Ethernet Chapitre 1 Ethernet 1.8 Format d une trame Ethernet Trame Ethernet == Paquet Ethernet 62 bits 2 bits Série alternée de 0 et de 1 Série de 2 bits à 1 Taille de la trame : 18 octets d entête + au maximum 1500 octets de données = 1518 octets 6 bytes 6 bytes 2 bytes de 46 bytes à 1500 bytes 4 bytes Adresse de destination Adresse de l émetteur Longueur du paquet (standard 802.3) Type du paquet (standard Ethernet) Données Frame Check Sequence La capacité de 1500 octets est appelée MTU (Maximum Transmission Unit). Il existe des Jumbo frames : trame de 9000 octets de données. Souvent non supporté par les équipements réseau. A éviter. c T.Besançon (v ) Administration UNIX ARS Partie 3 37 / 789

20 1 Ethernet 1.9 Address Resolution Protocol (ARP) Chapitre 1 Ethernet 1.9 Address Resolution Protocol (ARP) RFC 826 Le protocole ARP apporte la réponse à «comment dialoguer avec une autre machine IP du même brin Ethernet sans connaitre au préalable son adresse Ethernet». Synthétiquement le protocole fonctionne ainsi : Je suis la machine d adresse IP IP1 et d adresse Ethernet MAC1. Ecoutez moi tous sur le brin Ethernet. Je veux dialoguer avec la machine d adresse IP IP2. Que la machine avec cette adresse IP me communique son adresse Ethernet MAC2. J ai bien entendu. Je suis la machine avec IP2. Voici mon adresse Ethernet MAC2. Les autres machines en profitent pour noter la réponse. c T.Besançon (v ) Administration UNIX ARS Partie 3 38 / Ethernet 1.9 Address Resolution Protocol (ARP) QUI A L ADRESSE IP a.b.c.d? c T.Besançon (v ) Administration UNIX ARS Partie 3 39 / 789

21 1 Ethernet 1.9 Address Resolution Protocol (ARP) J AI L ADRESSE IP a.b.c.d c T.Besançon (v ) Administration UNIX ARS Partie 3 40 / Ethernet 1.10 Table ARP : commande arp, /proc/net/arp Chapitre 1 Ethernet 1.10 Table ARP : commande arp, /proc/net/arp Syntaxe : «arp -a» ou «arp -an» Exemple : % arp -a Net to Media Table: IPv4 Device IP Address Mask Flags Phys Addr eri0 solaris.example.org SP 00:03:ba:0f:15:35 c T.Besançon (v ) Administration UNIX ARS Partie 3 41 / 789

22 1 Ethernet 1.10 Table ARP : commande arp, /proc/net/arp Autre façon d obtenir la table ARP d une machine LINUX : % cat /proc/net/arp IP address HW type Flags HW address Mask Device x1 0x2 00:02:7E:21:F7:9C * eth x1 0x2 00:48:54:6B:E5:B0 * eth3 c T.Besançon (v ) Administration UNIX ARS Partie 3 42 / Ethernet 1.11 Surveillance ARP : commande arpwatch Chapitre 1 Ethernet 1.11 Surveillance ARP : commande arpwatch « ARPWATCH surveille les échanges du protocole ARP et stocke les adresses échangées. Attention : forte utilisation des switches désormais difficile d écouter les paquets qui ne nous sont pas destinés c T.Besançon (v ) Administration UNIX ARS Partie 3 43 / 789

23 1 Ethernet 1.11 Surveillance ARP : commande arpwatch Détection d une nouvelle machine Date: Tue, 17 Feb :07: (CET) From: arpwatch@math.jussieu.fr (Arpwatch) To: root@smtp.math.jussieu.fr Subject: new station hostname: <unknown> ip address: ethernet address: 0:1e:68:be:93:32 ethernet vendor: <unknown> timestamp: Tuesday, February 17, :07: c T.Besançon (v ) Administration UNIX ARS Partie 3 44 / Ethernet 1.11 Surveillance ARP : commande arpwatch Changement d adresse Ethernet sur une machine Date: Tue, 17 Feb :11: (CET) From: arpwatch@math.jussieu.fr (Arpwatch) To: root@smtp.math.jussieu.fr Subject: changed ethernet address (host dhcp.math.jussieu.fr) hostname: host dhcp.math.jussieu.fr ip address: ethernet address: 0:1e:68:be:93:32 ethernet vendor: <unknown> old ethernet address: 0:3:93:42:72:de old ethernet vendor: <unknown> timestamp: Tuesday, February 17, :11: previous timestamp: Tuesday, February 17, :22: delta: 2 hours c T.Besançon (v ) Administration UNIX ARS Partie 3 45 / 789

24 1 Ethernet 1.11 Surveillance ARP : commande arpwatch Flip flop d adresses Date: Tue, 17 Feb :11: (CET) From: arpwatch@math.jussieu.fr (Arpwatch) To: root@smtp.math.jussieu.fr Subject: flip flop hostname: <unknown> ip address: ethernet address: 0:3:93:3:8e:b8 ethernet vendor: <unknown> old ethernet address: 0:1f:5b:f6:29:90 old ethernet vendor: <unknown> timestamp: Tuesday, February 17, :11: previous timestamp: Tuesday, February 17, :11: delta: 39 seconds c T.Besançon (v ) Administration UNIX ARS Partie 3 46 / Ethernet 1.12 (Windows : : purge du cache ARP : netsh) Chapitre 1 Ethernet 1.12 (Windows : : purge du cache ARP : netsh) Une machine WINDOWS utilise un cache ARP comme n importe quelle autre machine faisant de l IP. On peut purger le cache ARP par la commande «netsh interface ip delete arpcache». c T.Besançon (v ) Administration UNIX ARS Partie 3 47 / 789

25 1 Ethernet 1.13 Reverse Address Resolution Protocol (RARP) Chapitre 1 Ethernet 1.13 Reverse Address Resolution Protocol (RARP) Le protocole répond à «je suis la machine d adresse Ethernet MAC1 ; qui peut me donner mon adresse IP?». Exemple de telles machines : stations UNIX sans disque (dite diskless) terminaux X, clients légers imprimantes réseau webcams réseau boitiers ethernet/usb ou ethernet/parallèle pour imprimante c T.Besançon (v ) Administration UNIX ARS Partie 3 48 / Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Chapitre 1 Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Question RARP : «je suis la machine d adresse Ethernet MAC1 ; qui peut me donner mon adresse IP?». Réponse : Dynamic Host Configuration Protocol (DHCP) RFC 2131 et RFC 2132 « « Port TCP 67 (port d écoute du serveur) Port TCP 68 (port de réponse du serveur) c T.Besançon (v ) Administration UNIX ARS Partie 3 49 / 789

26 1 Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Protocole DHCP CLIENT DHCP DHCPDISCOVER (broadcast) SERVEUR DHCP DHCPOFFER (unicast) DHCPREQUEST (broadcast) DHCPACK (unicast) c T.Besançon (v ) Administration UNIX ARS Partie 3 50 / Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Principe : 1 Une machine démarre dans l état «INIT» 2 Elle cherche un serveur DHCP en envoyant un paquet «DHCPDISCOVER». 3 Un ou plusieurs serveurs DHCP répondent par un paquet «DHCPOFFER» contenant une adresse IP et des options DHCP. 4 Le client sélectionne un serveur DHCP parmi ceux qui ont répondu. Par exemple, le premier. 5 Le client broadcaste un paquet «DHCPREQUEST» spécifiant l adresse IP retenue. 6 Le serveur retenu répond au client en lui envoyant un paquet «DHCPACK». 7 Après, le client posséde l adresse IP pour un laps de temps appelé lease. c T.Besançon (v ) Administration UNIX ARS Partie 3 51 / 789

27 1 Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Lorsqu une machine qui a obtenu une adresse IP via DHCP reboote, elle ne recommence pas exactement les étapes ci-dessus. Elle commence dans l état «INIT-REBOOT». Elle envoie un paquet «DHCPREQUEST» reprenant l adresse précédemment acquise. En cas de disponibilité de l adresse, le serveur répond par «DHCPACK». En cas de non disponibilité (par exemple, le portable a changé de réseau), un serveur DHCP répond par «DHCPNACK». A ce moment-là, la machine reprend à l étape 1 de ci-dessus. Mécanisme de détection de duplicate IP address : le serveur DHCP envoie un paquet «ICMP Echo» ; en cas de réponse, le serveur propose une autre adresse le client DHCP envoie un paquet «ARP» ; en cas de réponse, le client envoie un paquet «DHCPDECLINE» ; le serveur proposera alors une nouvelle adresse c T.Besançon (v ) Administration UNIX ARS Partie 3 52 / Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Exemple de dialogue DHCP Scenario : une machine A fonctionne en mode DHCP. On change sa carte réseau et la machine continue de fonctionner en mode DHCP. Au niveau du serveur DHCP, on voit : DHCPREQUEST for from 00:0c:29:44:44:0d via eri0: lease unavailable. <- 1 DHCPNAK on to 00:0c:29:44:44:0d via eri0 <- 2 DHCPDISCOVER from 00:0c:29:44:44:0d via eri0 <- 3 DHCPOFFER on to 00:0c:29:44:44:0d via eri0 <- 4 DHCPREQUEST for ( ) from 00:0c:29:44:44:0d via eri0 <- 5 DHCPACK on to 00:0c:29:44:44:0d via eri0 <- 6 c T.Besançon (v ) Administration UNIX ARS Partie 3 53 / 789

28 1 Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient 1 la machine A réclame l adresse IP qu elle obtenait avec sa carte réseau précédente 2 le serveur refuse cette adresse car il attribue les adresses en mode statique (une adresse ethernet bien précise = une adresse IP bien précise) 3 la machine demande donc poliment une adresse IP au serveur DHCP 4 le serveur DHCP propose une adresse IP 5 la machine accepte la machine et confirme l adresse IP au serveur DHCP 6 le serveur DHCP prend note de l affectation de l adresse IP c T.Besançon (v ) Administration UNIX ARS Partie 3 54 / Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Logiciel ISC DHCP « «ftp://ftp.isc.org/isc/dhcp/dhcp-3.0pl1.tar.gz» Fichier de configuration : en général «/etc/dhcp.conf» Pas de «SIGHUP» pour le reconfigurer en live. En cas de modification au fichier de configuration, il faut arrêter le démon «dhcpd» et le relancer. c T.Besançon (v ) Administration UNIX ARS Partie 3 55 / 789

29 1 Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Configuration d une machine LINUX via DHCP Sur Red Hat Linux, on peut dire à la machine de configurer son adresse réseau via DHCP au niveau de «/etc/sysconfig/network-scripts/ifcfg-eth0» : Configuration en mode dynamique : DEVICE = eth0 IPADDR = NETMASK = NETWORK = BROADCAST = GATEWAY = none ONBOOT = yes DYNAMIC = dhcp Configuration en mode statique : DEVICE=eth0 BOOTPROTO=static HWADDR=00:50:56:11:11:11 IPADDR= GATEWAY= NETMASK= ONBOOT=yes TYPE=Ethernet Au démarrage, la machine LINUX lancera alors le démon «dhclient» pour recevoir la configuration via DHCP (configuration possible via «/etc/dhclient.conf»). c T.Besançon (v ) Administration UNIX ARS Partie 3 56 / Ethernet 1.14 DHCP, dhcpd, dhcpd.conf, dhclient Possibilité de relayage DHCP DHCP SERVER DHCP agent DHCP CLIENT c T.Besançon (v ) Administration UNIX ARS Partie 3 57 / 789

30 1 Ethernet 1.15 Mode promiscuous Chapitre 1 Ethernet 1.15 Mode promiscuous En théorie une carte réseau n écoute que les paquets qui lui sont destinés. Si une carte Ethernet est en mode promiscuous, elle peut capturer des paquets qui ne lui sont pas destinés. c T.Besançon (v ) Administration UNIX ARS Partie 3 58 / Ethernet 1.15 Mode promiscuous FREEBSD La commande «ifconfig» indique l état promiscuous en cas de lancement d un programme faisant passer en mode promiscuous : # ifconfig -a... bge1: flags=8943<up,broadcast,running,promisc,simplex,multicast> mtu 150 options=1b<rxcsum,txcsum,vlan_mtu,vlan_hwtagging> inet netmask 0xffffffc0 broadcast inet netmask 0xffffffff broadcast inet netmask 0xffff0000 broadcast ether 00:19:bb:21:2f:01 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active... c T.Besançon (v ) Administration UNIX ARS Partie 3 59 / 789

31 1 Ethernet 1.15 Mode promiscuous Le passage en mode promiscuous est aussi notifié par le noyau qui remonte l information via «dmesg» : # dmesg... bge1: promiscuous mode enabled... bge1: promiscuous mode disabled... c T.Besançon (v ) Administration UNIX ARS Partie 3 60 / Ethernet 1.15 Mode promiscuous LINUX La commande «ifconfig» n indique pas l état promiscuous en cas de lancement d un programme faisant passer en mode promiscuous : # ifconfig -a... eth0 Link encap:ethernet HWaddr 00:11:09:5A:F0:D8 inet addr: Bcast: Mask: inet6 addr: fe80::211:9ff:fe5a:f0d8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes: (2.6 GiB) TX bytes: (3.3 GiB) Base address:0x2000 Memory:d d c T.Besançon (v ) Administration UNIX ARS Partie 3 61 / 789

32 1 Ethernet 1.15 Mode promiscuous Le passage en mode promiscuous est notifié par le noyau qui remonte l information via «dmesg» : # dmesg... device eth0 entered promiscuous mode... device eth0 left promiscuous mode... c T.Besançon (v ) Administration UNIX ARS Partie 3 62 / Ethernet 1.15 Mode promiscuous SOLARIS La commande «ifconfig» n indique pas l état promiscuous en cas de lancement d un programme faisant passer en mode promiscuous. c T.Besançon (v ) Administration UNIX ARS Partie 3 63 / 789

33 1 Ethernet 1.16 Capture de trames Ethernet : librairie libpcap Chapitre 1 Ethernet 1.16 Capture de trames Ethernet : librairie libpcap (en anglais library packet capture) Cf « C est une bibliothèque de programmation C spécialisée dans la capture de paquets réseau. Elle repose sur un driver réseau présent dans le noyau, le packet filter BPF. c T.Besançon (v ) Administration UNIX ARS Partie 3 64 / Ethernet 1.17 Capture de trames Ethernet : tcpdump Chapitre 1 Ethernet 1.17 Capture de trames Ethernet : tcpdump Cf « C est le logiciel de référence en ce qui concerne l analyse des trames IP circulant sur un réseau. Il est bâti au dessus de la libpcap qui fait tout le travail en fait. C est juste de l enrobage au dessus de libpcap. En cas de problème réseau, on utilisera ce logiciel si l origine du problème n est pas évidente. Exemple : # tcpdump -s 1500 host # tcpdump -s 1500 arp # tcpdump -s 1500 icmp # tcpdump -s 1500 dst sgbd.example.com port 5432 # tcpdump -s w fichier # tcpdump -s r fichier c T.Besançon (v ) Administration UNIX ARS Partie 3 65 / 789

34 1 Ethernet 1.18 Capture de trames Ethernet : wireshark (ethereal) Chapitre 1 Ethernet 1.18 Capture de trames Ethernet : wireshark (ethereal) « Ancien nom : «ethereal» (« C est un logiciel graphique d analyse des trames IP circulant sur un réseau. On l utilise conjointement à tcpdump : 1 on demande à «tcpdump» d enregistrer les trames : «tcpdump -s w enregistrement» 2 on demande à «ethereal» de relire a posteriori ce fichier d enregistrement : «ethereal enregistrement» c T.Besançon (v ) Administration UNIX ARS Partie 3 66 / Ethernet 1.18 Capture de trames Ethernet : wireshark (ethereal) c T.Besançon (v ) Administration UNIX ARS Partie 3 67 / 789

35 1 Ethernet 1.19 (Windows : : capture de trames Ethernet : wireshark.exe) Chapitre 1 Ethernet 1.19 (Windows : : capture de trames Ethernet : wireshark.exe) A completer... c T.Besançon (v ) Administration UNIX ARS Partie 3 68 / Ethernet 1.20 Wake On Lan Chapitre 1 Ethernet 1.20 Wake On Lan Sur les machines modernes, la carte réseau reste alimentée électriquement la carte réseau peut alors démarrer la carte mère sur réception de paquets réseau spéciaux et démarrer l OS = Wake On Lan c T.Besançon (v ) Administration UNIX ARS Partie 3 69 / 789

36 1 Ethernet 1.20 Wake On Lan c T.Besançon (v ) Administration UNIX ARS Partie 3 70 / Ethernet 1.20 Wake On Lan Manifestement dépend aussi du driver de la carte réseau : Manifestement dépend aussi de la bonne qualité du driver de la carte réseau : Salle de TP de la Formation Permanente Carte mère ASUS P4P800X Boot de Windows ; shutdown propre WOL possible Boot de Mandriva 2006 ; shutdown propre WOL impossible c T.Besançon (v ) Administration UNIX ARS Partie 3 71 / 789

37 1 Ethernet 1.20 Wake On Lan Comment contacter une machine? Envoi d un paquet Ethernet spécial : paquet UDP à destination du port «discard» (numéro 9) le plus souvent contenu du paquet UDP (dit magic sequence) : 6 fois «0xFF» 16 fois l adresse Ethernet Par exemple, pour réveiller la carte d adresse «01:02:03:04:05:06» : FFFFFFFFFFFF c T.Besançon (v ) Administration UNIX ARS Partie 3 72 / Ethernet 1.20 Wake On Lan Logiciels : «wakeonlan» : «wakeonlan» : «java -jar wakeonlan.jar -i :02:03:04:05:06» c T.Besançon (v ) Administration UNIX ARS Partie 3 73 / 789

38 Chapitre 2 Protocole IP c T.Besançon (v ) Administration UNIX ARS Partie 3 74 / Protocole IP 2.1 IP v4 / IP v6 Chapitre 2 Protocole IP 2.1 IP v4 / IP v6 Plusieurs versions de TCP/IP : 1 IP version 4 2 IP version 6 IP version 6 : revu plus tard page 142 c T.Besançon (v ) Administration UNIX ARS Partie 3 75 / 789

39 2 Protocole IP 2.2 Adresses IP Chapitre 2 Protocole IP 2.2 Adresses IP Quelques caractéristiques : protocole IP version 4 adresse IP sur 4 octets «a.b.c.d» a, b, c, d sont compris entre 0 et 255 et écrits en base 10 pour éviter des erreurs % man 3 inet... All numbers supplied as parts in a. notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; otherwise, the number is interpreted as decimal).... des organismes attribuent des lots d adresses aux sociétés (pour la France AFNIC : « c T.Besançon (v ) Administration UNIX ARS Partie 3 76 / Protocole IP 2.3 Adresses de réseaux : classes A, B et C Chapitre 2 Protocole IP 2.3 Adresses de réseaux : classes A, B et C Notion de classes d adresses : A, B et C : Classe A Format des adresses 7 bits 24 bits 0 netid hostid à bits 16 bits B C 1 0 netid hostid à bits 8 bits netid hostid à Devient obsolète. c T.Besançon (v ) Administration UNIX ARS Partie 3 77 / 789

40 2 Protocole IP 2.4 Adresses de réseaux : sous-réseaux, écriture CIDR Chapitre 2 Protocole IP 2.4 Adresses de réseaux : sous-réseaux, écriture CIDR (en anglais subnets) Un sous-réseau = découpage plus fin ou plus large que les classes A, B ou C. Le principe reste le même : une longueur N de bits imposés une longueur 32 - N de bits laissés variables Ecriture d une adresse réseau : «adresse-du-réseau/n» (écriture dite CIDR, Classless Inter Domain Routing) c T.Besançon (v ) Administration UNIX ARS Partie 3 78 / Protocole IP 2.4 Adresses de réseaux : sous-réseaux, écriture CIDR Par exemple : « /25» Signification : 25 bits imposés = 7 bits variables = < ><- 7 -> Conclusion : les adresses disponibles sur ce subnet vont de « » ( ) à « » ( ). c T.Besançon (v ) Administration UNIX ARS Partie 3 79 / 789

41 2 Protocole IP 2.4 Adresses de réseaux : sous-réseaux, écriture CIDR Combien d adresses IP utilisables par sous-réseau? Réponse : si N bits variables alors 2 N 2 : l adresse avec tous les bits variables à 0 est réservée pour désigner le sous-réseau l adresse avec tous les bits variables à 1 est réservée pour désigner l adresse de broadcast (voir page 88) Par exemple : « /25» 128 adresses dans le sous-réseau = = 126 adresses utilisables pour des machines c T.Besançon (v ) Administration UNIX ARS Partie 3 80 / Protocole IP 2.4 Adresses de réseaux : sous-réseaux, écriture CIDR Combien d adresses IP utilisables par sous-réseau? Masque Nombres d adresses Nombre d adresses utilisables CIDR / = = / = = / = = 254 / = = 126 / = = 62 / = = 30 / = = 14 / = = 6 / = = 2 / = = 0 c T.Besançon (v ) Administration UNIX ARS Partie 3 81 / 789

42 2 Protocole IP 2.5 Masque réseau, netmask Chapitre 2 Protocole IP 2.5 Masque réseau, netmask Le problème : comment la station A construit-elle les paquets Ethernet pour dialoguer avec la machine B, où que soit la station B? Deux cas de figure : 1 A et B sont sur le même réseau Ethernet local : A peut envoyer un paquet Ethernet directement à B 2 A et B ne sont pas sur le même réseau Ethernet local : A doit passer par un routeur intermédiaire. Il faut alors construire un paquet avec pour adresse Ethernet de destination l adresse Ethernet du routeur et non pas avec l adresse Ethernet de B. c T.Besançon (v ) Administration UNIX ARS Partie 3 82 / Protocole IP 2.5 Masque réseau, netmask Comment diagnostiquer si A et B sont sur le même réseau Ethernet ou pas? La solution : A et B sont sur le même réseau physique si IP(A) et IP(B) partagent une même propriété : avoir la même adresse de réseau. On calcule l adresse de réseau d une adresse A en appliquant un masque de bits sur l adresse IP de A. Le masque de bits est appelé le masque de réseau de A (ou netmask). IP(A) & netmask(a) = adresse-réseau(a) c T.Besançon (v ) Administration UNIX ARS Partie 3 83 / 789

43 2 Protocole IP 2.5 Masque réseau, netmask Comment diagnostiquer si A et B sont sur le même réseau Ethernet ou pas? En l occurence si : IP(A) & netmask(a) = IP(B) & netmask(a) (avec «&» désignant le «ET logique») Rappel sur le ET logique : bit A bit B bit A ET bit B c T.Besançon (v ) Administration UNIX ARS Partie 3 84 / Protocole IP 2.5 Masque réseau, netmask Le netmask se construit ainsi : la partie fixe des bits est mise à 1 la partie variable des bits est mise à 0 Bits Masque c T.Besançon (v ) Administration UNIX ARS Partie 3 85 / 789

44 2 Protocole IP 2.5 Masque réseau, netmask Exemple 1 : réseau « /25» Netmask : « » A : A : netmask(a) : < ><- 7 -> A & netmask(a) : B : B : netmask(a) : < ><- 7 -> B & netmask(a) : Donc les machines sont sur le même réseau. c T.Besançon (v ) Administration UNIX ARS Partie 3 86 / Protocole IP 2.5 Masque réseau, netmask Exemple 2 : réseau « /25» Netmask : « » A : A : netmask(a) : < ><- 7 -> A & netmask(a) : B : B : netmask(a) : < ><- 7 -> B & netmask(a) : Donc les machines ne sont pas sur le même réseau. c T.Besançon (v ) Administration UNIX ARS Partie 3 87 / 789

45 2 Protocole IP 2.6 Adresse de broadcast IP Chapitre 2 Protocole IP 2.6 Adresse de broadcast IP Chaque machine IP écoute un paquet IP avec l adresse de broadcast pour adresse de destination et répond peut-être suivant le type du paquet. Construction de l adresse de broadcast d une machine A dans le réseau «réseau/n» : les bits de la longueur N de bits restent inchangés les 32 - N bits (variables dans le subnet) sont mis à 1 c T.Besançon (v ) Administration UNIX ARS Partie 3 88 / Protocole IP 2.6 Adresse de broadcast IP Exemple 1 : réseau « /24» A : A : < ><- 8 --> netmask(a) : broadcast(a) : broadcast(a) : c T.Besançon (v ) Administration UNIX ARS Partie 3 89 / 789

46 2 Protocole IP 2.6 Adresse de broadcast IP Exemple 2 : réseau « /25» A : A : < ><- 7 -> netmask(a) : broadcast(a) : broadcast(a) : c T.Besançon (v ) Administration UNIX ARS Partie 3 90 / Protocole IP 2.6 Adresse de broadcast IP Exemple 3 : réseau « /26» A : A : < ><- 6-> netmask(a) : broadcast(a) : broadcast(a) : c T.Besançon (v ) Administration UNIX ARS Partie 3 91 / 789

47 2 Protocole IP 2.7 Unicast, Broadcast, Multicast Chapitre 2 Protocole IP 2.7 Unicast, Broadcast, Multicast Diffusion unicast c T.Besançon (v ) Administration UNIX ARS Partie 3 92 / Protocole IP 2.7 Unicast, Broadcast, Multicast Diffusion broadcast c T.Besançon (v ) Administration UNIX ARS Partie 3 93 / 789

48 2 Protocole IP 2.7 Unicast, Broadcast, Multicast Diffusion multicast c T.Besançon (v ) Administration UNIX ARS Partie 3 94 / Protocole IP 2.8 Adresse spéciale : adresse de loopback Chapitre 2 Protocole IP 2.8 Adresse spéciale : adresse de loopback Interface virtuelle de loopback d adresse IP « » L adresse « » est appelée «localhost». Permet de faire des connexions réseau avec soi-même. INTERNET APPL1 Adresse IP a.b.c.d Adresse IP APPL2 c T.Besançon (v ) Administration UNIX ARS Partie 3 95 / 789

49 2 Protocole IP 2.8 Adresse spéciale : adresse de loopback Adresse de loopback sur UNIX/LINUX A completer... c T.Besançon (v ) Administration UNIX ARS Partie 3 96 / Protocole IP 2.8 Adresse spéciale : adresse de loopback Adresse de loopback sur WINDOWS A completer... c T.Besançon (v ) Administration UNIX ARS Partie 3 97 / 789

50 2 Protocole IP 2.9 Adresses spéciales : adresses privées / RFC 1918 Chapitre 2 Protocole IP 2.9 Adresses spéciales : adresses privées / RFC 1918 RFC 1918 : adresses privées : « /8» « /12» « /16» Adresses utilisables sur des réseaux sans interconnexion avec Internet ou avec NAT (Network Address Translation ; par exemple : boites ADSL). c T.Besançon (v ) Administration UNIX ARS Partie 3 98 / Protocole IP 2.10 Adresses spéciales : autres adresses / RFC 3330 Chapitre 2 Protocole IP 2.10 Adresses spéciales : autres adresses / RFC 3330 RFC 3330 : Adresses Réseau Documentation « /8» "This" Network RFC1700, page 4 « /8» Private-Use Networks RFC1918 « /8» Public-Data Networks RFC1700, page 181 « /8» Cable Television Networks « /8» Reserved but subject to allocation RFC1797 « /8» Loopback RFC1700, page 5 « /16» Reserved but subject to allocation « /16» Link Local « /12» Private-Use Networks RFC1918 « /16» Reserved but subject to allocation c T.Besançon (v ) Administration UNIX ARS Partie 3 99 / 789

51 2 Protocole IP 2.10 Adresses spéciales : autres adresses / RFC 3330 RFC 3330 (suite) : Adresses Réseau Documentation « /24» Reserved but subject to allocation « /24» Test-Net « /24» 6to4 Relay Anycast RFC3068 « /16» Private-Use Networks RFC1918 « /15» Network Interconnect Device RFC2544 Benchmark Testing « /24» Reserved but subject to allocation « /4» Multicast RFC3171 « /4» Reserved for Future Use RFC1700, page 4 c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.11 Encapsulation des paquets Chapitre 2 Protocole IP 2.11 Encapsulation des paquets Principe des poupées russes. c T.Besançon (v ) Administration UNIX ARS Partie / 789

52 2 Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet data trailer Ethernet c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet Trame ARP trailer Ethernet c T.Besançon (v ) Administration UNIX ARS Partie / 789

53 2 Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet Trame IP trailer Ethernet c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet Trame IP trailer Ethernet header IP Trame UDP c T.Besançon (v ) Administration UNIX ARS Partie / 789

54 2 Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet Trame IP trailer Ethernet header IP Trame TCP c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.11 Encapsulation des paquets Trame Ethernet header Ethernet Trame IP trailer Ethernet header IP Trame ICMP c T.Besançon (v ) Administration UNIX ARS Partie / 789

55 2 Protocole IP 2.12 Configuration d adresse IP : ifconfig Chapitre 2 Protocole IP 2.12 Configuration d adresse IP : ifconfig (en anglais interface configuration) La commande «ifconfig» sert à régler les paramètres des cartes réseau : # ifconfig le0 inet # ifconfig le0 netmask 0xffffff80 # ifconfig le0 broadcast # ifconfig -a lo0: flags=849<up,loopback,running,multicast> mtu 8232 inet netmask ff le0: flags=863<up,broadcast,notrailers,running,multicast> mtu 1500 inet netmask ffffff80 broadcast ether 8:0:20:83:12:4a c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.12 Configuration d adresse IP : ifconfig Sur une machine Linux, les cartes réseau ont pour noms «eth0», «eth1», «eth2», etc. Sur une machine Linux, la paramètrage réseau de la carte «eth0» se trouve au niveau du fichier «/etc/sysconfig/network-scripts/ifcfg-eth0» (ainsi de suite pour les autres interfaces) : DEVICE=eth0 BOOTPROTO=static BROADCAST= IPADDR= NETMASK= NETWORK= ONBOOT=yes GATEWAY= TYPE=Ethernet USERCTL=no PEERDNS=no La commande «dmesg» renvoie la liste des interfaces. c T.Besançon (v ) Administration UNIX ARS Partie / 789

56 2 Protocole IP 2.12 Configuration d adresse IP : ifconfig Sur une machine SOLARIS, les cartes réseau ont des noms dépendant du type de carte. Par exemple «le0», «eri0», «qfe0» + «qfe1» + «qfe2» + «qfe3» (carte quad port 10/100), etc. Sur une machine SOLARIS, la paramètrage réseau de la carte XYZ se trouve au niveau du fichier «/etc/hostname.xyz» : -rw-r--r-- 1 root root 19 Dec 4 01:35 /etc/hostname.eri0 qui contient le hostname associé à la carte : hostname adresse réseau via «/etc/hosts» Broadcast, netmask déduits La commande «dmesg» renvoie la liste des interfaces. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.13 Adresses IP virtuelles Chapitre 2 Protocole IP 2.13 Adresses IP virtuelles A completer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

57 2 Protocole IP 2.14 Configuration d adresses IP virtuelles : ifconfig Chapitre 2 Protocole IP 2.14 Configuration d adresses IP virtuelles : ifconfig Sur une machine Linux, si la carte réseau s appelle par exemple «eth0», alors les adresses virtuelles utiliseront les interfaces réseau virtuelles de noms «eth0:0», «eth0:1», «eth0:2», etc. Sur une machine Linux, la paramètrage réseau de l adresse virtuelle «eth0:0» se trouve au niveau du fichier «/etc/sysconfig/network-scripts/ifcfg-eth0:0» (ainsi de suite pour les autres interfaces) : DEVICE=eth0:0 BOOTPROTO=static BROADCAST= IPADDR= NETMASK= NETWORK= ONBOOT=yes TYPE=Ethernet USERCTL=no PEERDNS=no c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.14 Configuration d adresses IP virtuelles : ifconfig Sur une machine SOLARIS, si la carte réseau s appelle par exemple «eri0», alors les adresses virtuelles utiliseront les interfaces réseau virtuelles de noms «eri0:1», «eri0:2», «eri0:3», etc. Sur une machine SOLARIS, la paramètrage réseau d une interface virtuelle «eri0:1» se trouvera donc au niveau du fichier «/etc/hostname.eri0:1» : -rw-r--r-- 1 root root 19 Dec 4 01:35 /etc/hostname.eri0:1 qui contient le hostname associé à l interface virtuelle : hostname adresse réseau via «/etc/host» Broadcast, netmask déduits Manuellement «ifconfig eri0 addif /prefix up» c T.Besançon (v ) Administration UNIX ARS Partie / 789

58 2 Protocole IP 2.15 (Windows 98 : : winipcfg.exe) Chapitre 2 Protocole IP 2.15 (Windows 98 : : winipcfg.exe) La commande «winipcfg.exe» permet de connaitre en mode graphique la configuration réseau des interfaces. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.15 (Windows 98 : : winipcfg.exe) c T.Besançon (v ) Administration UNIX ARS Partie / 789

59 2 Protocole IP 2.16 (Windows : : ipconfig.exe) Chapitre 2 Protocole IP 2.16 (Windows : : ipconfig.exe) La commande «ipconfig.exe» permet de connaitre en mode ligne de commande la configuration réseau des interfaces. interfaces DHCP etc. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.16 (Windows : : ipconfig.exe) c T.Besançon (v ) Administration UNIX ARS Partie / 789

60 2 Protocole IP 2.16 (Windows : : ipconfig.exe) Libération d une adresse DHCP / Renouvellement d une adresse DHCP c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.17 (Windows : : netsh.exe) Chapitre 2 Protocole IP 2.17 (Windows : : netsh.exe) La commande «netsh» permet de configurer en mode ligne de commande beaucoup d aspects réseau : configuration des interfaces configuration DHCP configuration du firewall Microsoft configuration WIFI configuration IPSEC etc. c T.Besançon (v ) Administration UNIX ARS Partie / 789

61 2 Protocole IP 2.18 Connexions IP / ports IP Chapitre 2 Protocole IP 2.18 Connexions IP / ports IP Une connexion IP est constituée des éléments suivants : une adresse IP source un numéro de port source sur la machine de départ une adresse IP de destination un numéro de port sur la machine de destination protocole TCP ou UDP IP1 IP2 port 1 port 2 c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.18 Connexions IP / ports IP En pratique il y a 3 catégories de port : Les Well Known Ports de 0 à 1023 Les Registered Ports de 1024 à Les Dynamic and/or Private Ports de à Attention : Sur UNIX, la fonction C obtenant un port source < 1024 ne fonctionne que pour l UID 0. Sur Windows, la fonction C obtenant un port source < 1024 fonctionne quel que soit l UID c T.Besançon (v ) Administration UNIX ARS Partie / 789

62 2 Protocole IP 2.19 Fichier /etc/services Chapitre 2 Protocole IP 2.19 Fichier /etc/services Le fichier «/etc/services» mentionne des triplets (numéro de port, protocole, nom du service). On peut obtenir un triplet officiellement pour un programme à soi auprès de l IANA « Le fichier «/etc/services» sert à convertir un port numérique en un nom symbolique plus parlant. Voir les fonctions C «getservbyname()», «getservbyport()», «getservent()». ATTENTION : Le fichier «/etc/services» n indique pas les services réseau activés sur la machine. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.19 Fichier /etc/services Extrait d un fichier «/etc/services» :... chargen 19/tcp ttytst source #Character Generator chargen 19/udp ttytst source #Character Generator ftp-data 20/tcp #File Transfer [Default Data] ftp-data 20/udp #File Transfer [Default Data] ftp 21/tcp #File Transfer [Control] ftp 21/udp #File Transfer [Control] ssh 22/tcp #Secure Shell Login ssh 22/udp #Secure Shell Login telnet 23/tcp telnet 23/udp smtp 25/tcp mail #Simple Mail Transfer smtp 25/udp mail #Simple Mail Transfer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

63 2 Protocole IP 2.20 Liste des ports réseau actifs : netstat -a, netstat -an Chapitre 2 Protocole IP 2.20 Liste des ports réseau actifs : netstat -a, netstat -an La commande «netstat -a» renvoie la liste des connexions réseau établies ou en attente d établissement de connexion. Les noms affichés proviennent de «/etc/services» : % netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.ssh *.* LISTEN tcp *.ssh *.* LISTEN udp4 0 0 *.syslog *.* udp6 0 0 *.syslog *.* udp4 0 0 *.bootpc *.* Active UNIX domain sockets... c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.20 Liste des ports réseau actifs : netstat -a, netstat -an La commande «netstat -an» renvoie la liste des connexions réseau établies ou en attente d établissement de connexion, sans les traduire en noms via «/etc/services». Ils sont affichés sous forme numérique : % netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.22 *.* LISTEN tcp *.22 *.* LISTEN udp4 0 0 *.514 *.* udp6 0 0 *.514 *.* udp4 0 0 *.68 *.* Active UNIX domain sockets... c T.Besançon (v ) Administration UNIX ARS Partie / 789

64 2 Protocole IP 2.21 (Windows : : Liste des ports réseau actifs : netstat.exe) Chapitre 2 Protocole IP 2.21 (Windows : : Liste des ports réseau actifs : netstat.exe) Même principe sur UNIX : Microsoft Windows XP [Version ] (C) Copyright Microsoft Corp. C:\Documents and Settings\ars>netstat -an more Active Connections Proto Local Address Foreign Address State TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING TCP : :0 LISTENING UDP :445 *:* UDP :500 *:*... c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.22 Liste des connexions réseau : lsof Chapitre 2 Protocole IP 2.22 Liste des connexions réseau : lsof (en anglais List of open files) Site : ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/ «lsof» permet de connaître les filedescriptors ouverts sur une machine UNIX. Cela comprend les connexions réseau. Par exemple, pour voir quels processus utilisent la partition «/var/run» : % lsof /var/run COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME lpd 410 daemon 6u VREG 0, /var/run (swap) dhcpd root 6w VREG 0, /var/run (swap) c T.Besançon (v ) Administration UNIX ARS Partie / 789

65 2 Protocole IP 2.22 Liste des connexions réseau : lsof Par exemple pour voir qui utilise une certaine connexion TCP : % lsof -i tcp:32771 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME inetd 320 root 18u IPv4 0x f350 0t0 TCP *:32771 (LISTEN) Par exemple pour voir qui utilise une certaine connexion UDP : % lsof -i UDP@ :3853 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ss_logd 232 root 3u IPv4 0x30001d961c0 0t0 UDP localhost:3853 (Idle) (format «[protocol][@hostname hostaddr][:service port]») c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.23 (Windows : : Liste des connexions réseau : tcpview.exe) Chapitre 2 Protocole IP 2.23 (Windows : : Liste des connexions réseau : tcpview.exe) Logiciel TCPVIEW sur « c T.Besançon (v ) Administration UNIX ARS Partie / 789

66 2 Protocole IP 2.23 (Windows : : Liste des connexions réseau : tcpview.exe) TCPVIEW a une version en ligne de commande : TCPVCON c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.24 Commande de connexion : telnet Chapitre 2 Protocole IP 2.24 Commande de connexion : telnet Syntaxe : telnet host Exemples d utilisation : connexion à une machine UNIX connexion à une imprimante connexion à un équipement réseau etc. A chaque fois que ce sera possible, préférer une connexion shell distante en utilisant SSH. c T.Besançon (v ) Administration UNIX ARS Partie / 789

67 2 Protocole IP 2.24 Commande de connexion : telnet Autre syntaxe importante : telnet host port Exemples d utilisation : connexion manuelle à un serveur POP connexion manuelle à un serveur IMAP connexion manuelle à un serveur HTTP etc. Non remplaçable par SSH. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.24 Commande de connexion : telnet Exemple : connexion à une machine UNIX % telnet server.example.com Trying Connected to server.example.com. Escape character is ^]. SunOS 5.7 login: besancon Password: XXXXXXXX Last login: Sun Oct 12 15:18:22 from ppp-3 Sun Microsystems Inc. SunOS 5.5 Generic November 1995 server% c T.Besançon (v ) Administration UNIX ARS Partie / 789

68 2 Protocole IP 2.24 Commande de connexion : telnet Exemple : connexion à une imprimante % telnet hp4100.example.com Trying Connected to hp4100.example.com. Escape character is ^]. HP JetDirect Password: XXXXXXXX You are logged in Please type "?" for HELP, or "/" for current settings > / ===JetDirect Telnet Configuration=== Firmware Rev. : G MAC Address : 00:30:c1:0a:45:b2 Config By : USER SPECIFIED c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.24 Commande de connexion : telnet > exit IP Address : Subnet Mask : Default Gateway : Syslog Server : Not Specified Idle Timeout : 90 Seconds Set Cmnty Name : Not Specified Host Name : Not Specified Default Get Cmnty : Enabled DHCP Config : Disabled Passwd : Enabled IPX/SPX : Disabled DLC/LLC : Disabled Ethertalk : Enabled Banner page : Disabled EXITING WITHOUT SAVING ANY ENTRIES > Connection closed by foreign host. c T.Besançon (v ) Administration UNIX ARS Partie / 789

69 2 Protocole IP 2.24 Commande de connexion : telnet Exemple : interruption d une connexion par Ctrl-] (Control crochet fermant) % telnet obsolete.example.com Trying Connected to obsolete.example.com. Escape character is ^]. telnet login: besancon Password: XXXXXXXX Login incorrect login: ^] <-- taper Ctrl-] telnet> quit Connection closed. c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.24 Commande de connexion : telnet Exemple : tentative de connexion à une machine sans telnet % telnet notelnet.example.com Trying telnet: connect to address : Connection refused telnet: Unable to connect to remote host c T.Besançon (v ) Administration UNIX ARS Partie / 789

70 2 Protocole IP 2.24 Commande de connexion : telnet Humour Faire «telnet towel.blinkenlights.nl» c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.25 (Windows : : Commande de connexion : telnet.exe) Chapitre 2 Protocole IP 2.25 (Windows : : Commande de connexion : telnet.exe) Programme «telnet.exe» : c T.Besançon (v ) Administration UNIX ARS Partie / 789

71 2 Protocole IP 2.26 Duplicate IP address Chapitre 2 Protocole IP 2.26 Duplicate IP address Un problème régulier : les duplicate IP addresses : deux machines sur le même réseau Ethernet ont la même adresse IP Le pire scenario : l usurpateur prend l adresse du routeur par défaut. Solution : tracer les adresses Ethernet au niveau des tables ARP des switches c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.26 Duplicate IP address Symptôme d un duplicate IP address : un Apple MacOS X affiche : c T.Besançon (v ) Administration UNIX ARS Partie / 789

72 2 Protocole IP 2.27 IP v6 Chapitre 2 Protocole IP 2.27 IP v6 1.6e+09 Total address space allocated 1.4e e+09 Addresses allocated 1e+09 8e+08 6e+08 4e+08 2e Year c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.27 IP v6 5e+09 Total address space allocated 4.5e+09 4e e+09 Addresses allocated 3e e+09 2e e+09 1e+09 5e Year Epuisement prévu des numéros IP création de IP v6. c T.Besançon (v ) Administration UNIX ARS Partie / 789

73 2 Protocole IP 2.27 IP v6 From: James Carlson To: Subject: Re: (IPng) GENERAL IPNG ISSUES Date: Mon, 26 Sep 94 07:29: >> PS why do people say that 16 bytes is enough to address the people >> on the entire planet squillions of times over when addresses relate >> to location geography? 16 bytes is 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456. This is a humorously large address space. Taking a SWAG at the size of the Earth, about 201,062,400 square miles, this comes to around 1,692,421,690,584,308,470,720,406,239,216 addresses per square mile of Earth s surface, or about 421,578,297,421,497,485,189 addresses per square inch. Even if we chop off three bytes to indicate galaxy, solar system and planet, we d still have 25,128,024 addresses per square *mil* here on Earth. Pathology will never be the same after every microbe has its own address... c T.Besançon (v ) Administration UNIX ARS Partie / Protocole IP 2.28 Annexe 1 Chapitre 2 Protocole IP 2.28 Annexe 1 Ci joint dans la version imprimée de ce cours, un diagramme d états de TCP/IP. c T.Besançon (v ) Administration UNIX ARS Partie / 789

74

75 2 Protocole IP 2.29 Annexe 2 Chapitre 2 Protocole IP 2.29 Annexe 2 Ci joint dans la version imprimée de ce cours, un tableau du top 10% des AS fournissant des prefixes IPv6. c T.Besançon (v ) Administration UNIX ARS Partie / 789

76 « Each network in the global Internet has a unique Autonomous System (AS) number. An Autonomous System can be an Internet Service Provider (ISP), Enterprise network, content provider or any other sort of network. Each AS number announces one or more prefixes. By using Geo IP libraries we are able to determine a country for each prefix. This in turn allows us to determine the unique number of networks (AS numbers) per country. Doing this for both IPv4 as well as IPv6 will result in the IPv4/IPv6 deployment ratio. Let s look at for example at Canada. There are 816 Autonomous Systems that originate a prefix registered as in use in Canada. If we look at the IPv6 routing tables we see that 50 Autonomous Systems announce a Canadian IPv6 prefix. This results in an IPv6 deployment percentage of 6.1 TAB. 1: Top 10% Country code Country Ipv6 deployment rate Ipv6 network / Ipv4 networks JE Jersey 100% 1 / 1 CU Cuba 75% 3 / 4 OM Oman 50% 1 / 2 MC Monaco 50% 1 / 2 VA Holy See (Vatican City State) 50% 1 / 2 FJ Fiji 50% 1 / 2 TN Tunisia 33% 1 / 3 ML Mali 33% 1 / 3 UY Uruguay 31% 8 / 26 EE Estonia 26% 10 / 39 BT Bhutan 25% 1 / 4 SN Senegal 25% 1 / 4 IM Isle of Man 25% 1 / 4 LU Luxembourg 24% 10 / 42 LK Sri Lanka 23% 3 / 13 IS Iceland 21% 6 / 29 EU 20% 22 / 109 CZ Czech Republic 19% 34 / 176 NZ New Zealand 18% 35 / 194 JP Japan 17% 92 / 545 CI Cote D Ivoire 17% 1 / 6 NL Netherlands 17% 85 / 511 MY Malaysia 17% 13 / 78 MU Mauritius 17% 1 / 6 VE Venezuela 16% 6 / 38 PT Portugal 15% 11 / 75 CR Costa Rica 15% 2 / 13 TW Taiwan, Province of China 15% 18 / 122 RW Rwanda 14% 1 / 7 NO Norway 14% 17 / 120 ZA South Africa 14% 13 / 92 VI Virgin Islands, U.s. 14% 1 / 7 HT Haiti 14% 1 / 7 IE Ireland 14% 18 / 130 MT Malta 13% 3 / 23 DE Germany 13% 149 / 1183 Suite à la page suivante... 1

77 TAB. 1: Top 10% Country code Country Ipv6 deployment rate Ipv6 network / Ipv4 networks QA Qatar 13% 1 / 8 LI Liechtenstein 13% 2 / 15 VN Viet Nam 12% 6 / 50 AN Netherlands Antilles 12% 2 / 17 CH Switzerland 12% 51 / 437 EG Egypt 11% 5 / 46 SE Sweden 11% 38 / 344 TT Trinidad and Tobago 11% 1 / 9 SK Slovakia 10% 8 / 83 2

78 2 Protocole IP 2.30 Annexe 3 Chapitre 2 Protocole IP 2.30 Annexe 3 Ci joint dans la version imprimée de ce cours, un article intitué «Introduction à NETFLOW» du numéro 47 de Janvier/Février 2010 de MISC. Adresse web : « c T.Besançon (v ) Administration UNIX ARS Partie / 789

79

80

81

82

83

84 Chapitre 3 Routage IP par défaut c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.1 Notion de routage Chapitre 3 Routage IP par défaut 3.1 Notion de routage Routage : acheminement des paquets IP à leur destination selon un chemin déterminé par la destination Cas le plus simple : routage par défaut : tous les paquets IP sont acheminés vers un routeur qui les transmet plus loin. Les autres cas : protocoles spécialisés : ROUTED, BGP, OSPF, etc. (voir cours réseau) Un cas très spécial : routage selon l adresse IP source : policy based routing Attention : souvent un hack au niveau de l OS! c T.Besançon (v ) Administration UNIX ARS Partie / 789

85 3 Routage IP par défaut 3.2 Relation entre routage IP et paquets ethernet Chapitre 3 Routage IP par défaut 3.2 Relation entre routage IP et paquets ethernet machine A ETH = 11:22:33:44:55:66 IP = E ETH src = 11:22:33:44:55:66 ETH dest = AA:BB:CC:11:11:11 T H IP src = I IP dest = P IP data I P IP src = IP dest = IP data ROUTEUR ETH = AA:BB:CC:11:11:11 IP = ETH = AA:BB:CC:22:22:22 IP = machine B ETH = 77:88:99:00:AA:BB IP = E T ETH src = AA:BB:CC:22:22:22 ETH dest = 77:88:99:00:AA:BB H IP src = I IP dest = P IP data c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.3 Routage par défaut Chapitre 3 Routage IP par défaut 3.3 Routage par défaut Routage par défaut : tous les paquets IP sont acheminés vers un routeur qui les transmet plus loin. La destination du routage par défaut : le réseau « » En utilisant la commande «netstat» (voir page 155) et l option «-n», on voit bien ce réseau spécial : % netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt * U default UG % netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt U UG c T.Besançon (v ) Administration UNIX ARS Partie / 789

86 3 Routage IP par défaut 3.4 Configuration du routage LINUX : route Chapitre 3 Routage IP par défaut 3.4 Configuration du routage LINUX : route La commande «route» sert à configurer le routage. # route add default gw (en anglais gw = gateway = routeur) Sur une machine LINUX, se reporter au fichier «/etc/sysconfig/network» : NETWORKING=yes FORWARD_IPV4=false HOSTNAME=pcars5.formation.jussieu.fr DOMAINNAME=formation.jussieu.fr NISDOMAIN=real.world GATEWAY= GATEWAYDEV=eth0 c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.5 Configuration du routage SOLARIS : route Chapitre 3 Routage IP par défaut 3.5 Configuration du routage SOLARIS : route La commande «route» sert à configurer le routage. # route add default Sur une machine SOLARIS, se reporter au fichier «/etc/defaultrouter» : c T.Besançon (v ) Administration UNIX ARS Partie / 789

87 3 Routage IP par défaut 3.6 (Windows : : route.exe) Chapitre 3 Routage IP par défaut 3.6 (Windows : : route.exe) A completer... c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.7 Routage : netstat Chapitre 3 Routage IP par défaut 3.7 Routage : netstat La commande «netstat -r» renvoie la table de routage d une machine UNIX : % netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface UGH U le U 3 0 le0 default UG UH lo0 c T.Besançon (v ) Administration UNIX ARS Partie / 789

88 3 Routage IP par défaut 3.8 (Windows : : netstat.exe) Chapitre 3 Routage IP par défaut 3.8 (Windows : : netstat.exe) Même principe sur UNIX : C:\Documents and Settings\ars>netstat -rn Route Table =========================================================================== Interface List 0x1... MS TCP Loopback interface 0x c VMware Virtual Ethernet Adapter for VMnet2 0x c VMware Virtual Ethernet Adapter for VMnet8 0x c VMware Virtual Ethernet Adapter for VMnet1 0x b Dell TrueMobile 1400 Dual Band WLAN Mini-PCI Card - Packet 0x d 56 ad cc be... Broadcom 440x 10/100 Integrated Controller - Packet Schedu =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.8 (Windows : : netstat.exe) =========================================================================== Persistent Routes: None c T.Besançon (v ) Administration UNIX ARS Partie / 789

89 3 Routage IP par défaut 3.9 Test de connectivité : ping Chapitre 3 Routage IP par défaut 3.9 Test de connectivité : ping La commande «ping» teste si une machine répond au niveau réseau. % ping localhost localhost is alive On peut parfois pinger l adresse de broadcast : % /usr/sbin/ping -s PING : 1 data bytes 9 bytes from sunars1.formation.jussieu.fr ( ): icmp_seq=0. 9 bytes from sunars2.formation.jussieu.fr ( ): icmp_seq=0. 9 bytes from sunars4.formation.jussieu.fr ( ): icmp_seq=0. 9 bytes from sunars3.formation.jussieu.fr ( ): icmp_seq=0. 9 bytes from r-formation.formation.jussieu.fr ( ): icmp_seq=0. 9 bytes from sunars1.formation.jussieu.fr ( ): icmp_seq=1. 9 bytes from sunars2.formation.jussieu.fr ( ): icmp_seq=1. 9 bytes from sunars4.formation.jussieu.fr ( ): icmp_seq=1. 9 bytes from sunars3.formation.jussieu.fr ( ): icmp_seq=1. 9 bytes from r-formation.formation.jussieu.fr ( ): icmp_seq=1. ^C PING Statistics packets transmitted, 10 packets received, 5.00 times amplification c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.10 Test de connectivité : fping, hping Chapitre 3 Routage IP par défaut 3.10 Test de connectivité : fping, hping Autres utilitaires parents de PING : FPING : « HPING : « c T.Besançon (v ) Administration UNIX ARS Partie / 789

90 3 Routage IP par défaut 3.11 (Windows : : ping.exe) Chapitre 3 Routage IP par défaut 3.11 (Windows : : ping.exe) Même principe sur UNIX : C:\Documents and Settings\ars>ping Pinging with 32 bytes of data: Reply from : bytes=32 time<1ms TTL=128 Reply from : bytes=32 time<1ms TTL=128 Reply from : bytes=32 time<1ms TTL=128 Reply from : bytes=32 time<1ms TTL=128 Ping statistics for : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.12 Test de connectivité : traceroute Chapitre 3 Routage IP par défaut 3.12 Test de connectivité : traceroute La commande «traceroute» permet de tester si une machine est joignable. Elle renvoie les intermédiaires réseau qui route notre acheminement vers la machine distante. Syntaxe : «traceroute machine» % traceroute ftp.lip6.fr traceroute to nephtys.lip6.fr ( ), 30 hops max, 40 byte packets 1 yacht ( ) 0 ms 0 ms 0 ms 2 renater ( ) 2 ms 1 ms 1 ms ( ) 3 ms 1 ms 1 ms ( ) 2 ms 1 ms 1 ms ( ) 2 ms 1 ms 1 ms 6 jussieu.rap.prd.fr ( ) 2 ms 2 ms 2 ms 7 nephtys.lip6.fr ( ) 2 ms 2 ms 2 ms Le nombre d intermédiaires n est pas proportionnel à l éloignement géographique de la machine destination. c T.Besançon (v ) Administration UNIX ARS Partie / 789

91 3 Routage IP par défaut 3.13 (Windows : : tracert.exe) Chapitre 3 Routage IP par défaut 3.13 (Windows : : tracert.exe) A completer... c T.Besançon (v ) Administration UNIX ARS Partie / Routage IP par défaut 3.14 Machine LINUX routeur Chapitre 3 Routage IP par défaut 3.14 Machine LINUX routeur Routeur LINUX = une machine LINUX avec deux cartes réseau Les paquets réseau doivent être routés d une interface réseau à une autre interface réseau. Activation via «/proc/sys/net/ipv4/ip_forward» : 0 : les paquets ne sont pas routés d une interface à une autre interface 1 : les paquets sont routés d une interface à une autre interface c T.Besançon (v ) Administration UNIX ARS Partie / 789

92 Chapitre 4 Domain Name Server (DNS) c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.1 Principes du DNS Chapitre 4 Domain Name Server (DNS) 4.1 Principes du DNS Impossibilité pratique de maintenir à jour les fichiers «/etc/hosts». remplacement par un mécanisme d annuaire réparti dont chacun gère sa entrée propre : le Domain Name Server Particularités de la base de données du DNS : répartie petite avec une faible fréquence de changements des données hiérarchisée accès en consultation uniquement ; pas de requête de modification c T.Besançon (v ) Administration UNIX ARS Partie / 789

93 4 Domain Name Server (DNS) 4.2 Zone DNS Chapitre 4 Domain Name Server (DNS) 4.2 Zone DNS zone DNS : reflet de l aspect réparti et hiérarchisé du DNS partie contigüe de l arbre une zone parente délègue une zone fille à un ou plusieurs serveurs d informations (nameservers) sur la zone fille. com net fr... wanadoo jussieu formation... www www ssh c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.3 Requête d interrogation du DNS Chapitre 4 Domain Name Server (DNS) 4.3 Requête d interrogation du DNS Le DNS est bâti selon un modèle client serveur Cf logiciel DNSTRACER sur « c T.Besançon (v ) Administration UNIX ARS Partie / 789

94 4 Domain Name Server (DNS) 4.3 Requête d interrogation du DNS Le DNS utilise des root nameservers : Pour assurer un service fiable, une zone est servie par un nameserver primaire et plusieurs nameservers secondaires de secours qui se synchronisent entre eux. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.3 Requête d interrogation du DNS Principe de mémorisation des informations passées recueillies pour accélérer les réponses aux requêtes. L information a une date de péremption (TTL = Time To Live). Le serveur qui mémorise un record DNS n a pas autorité dessus. Chaque enregistrement de la base de données a : une classe ; la plus courante : IN (Internet) un type : A, PTR, NS, SOA, MX, CNAME,... et est donc de la forme : (classe, type, clé, valeur, TTL) Une requête ressemble alors à : (classe, type, clé,?,?) (classe, *, clé,?,?) c T.Besançon (v ) Administration UNIX ARS Partie / 789

95 4 Domain Name Server (DNS) 4.4 Implémentation : BIND, named Chapitre 4 Domain Name Server (DNS) 4.4 Implémentation : BIND, named URL : « Démon «named» Fichier de configuration «/etc/named.conf» (en général). Directory «/etc/namedb» stockant les fichiers de zone (en général). c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.4 Implémentation : BIND, named Exemple 1 : Pour connaitre la version de «named» : % dig ns.example.com version.bind chaos txt ; <<>> DiG 8.2 <<>> ns.example.com version.bind chaos txt ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT "bind 9" ;; Total query time: 3 msec ;; FROM: client.example.com to SERVER: default ;; WHEN: Mon Sep 30 00:20: ;; MSG SIZE sent: 30 rcvd: 49 c T.Besançon (v ) Administration UNIX ARS Partie / 789

96 4 Domain Name Server (DNS) 4.4 Implémentation : BIND, named Exemple 2 : Pour connaitre la version de «named» : % dig dmi.ens.fr version.bind chaos txt ; <<>> DiG <<>> dmi.ens.fr version.bind chaos txt ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4 ;; QUESTION SECTION: ;dmi.ens.fr. IN A ;; ANSWER SECTION: dmi.ens.fr IN A ;; AUTHORITY SECTION: ens.fr IN NS oseille.ens.fr. ens.fr IN NS dmi.ens.fr. ens.fr IN NS ext.lri.fr. ens.fr IN NS ns2.nic.fr. ens.fr IN NS clipper.ens.fr. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.4 Implémentation : BIND, named ;; ADDITIONAL SECTION: ext.lri.fr IN A ns2.nic.fr IN A clipper.ens.fr IN A oseille.ens.fr IN A ;; Query time: 831 msec ;; SERVER: #53( ) ;; WHEN: Mon Sep 30 00:19: ;; MSG SIZE rcvd: 210 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.2.1" ;; Query time: 42 msec ;; SERVER: #53( ) ;; WHEN: Mon Sep 30 00:19: ;; MSG SIZE rcvd: 48 c T.Besançon (v ) Administration UNIX ARS Partie / 789

97 4 Domain Name Server (DNS) 4.5 F.root-servers.net (vieille version) Chapitre 4 Domain Name Server (DNS) 4.5 F.root-servers.net (vieille version) OBSOLÈTE mais laissé pour se faire une idée c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.5 F.root-servers.net (vieille version) (cf « The Internet Software Consortium is proud to operate one of 13 root DNS servers as a public service to the Internet. The ISC has operated «F.root-servers.net» for the IANA ( since F ( answers more than 272 million DNS queries per day, making it one of the busiest DNS servers in the world. In fact, it is often the busiest root nameserver on the Internet. F is a virtual server made up of multiple (currently two) HP AlphaServers, donated to us by HP s Western Research Laboratory ( Each server is a HP ES40 AlphaServer with 4 500mhz CPUs and 8Gig of RAM, and runs ISC BIND as its DNS server. c T.Besançon (v ) Administration UNIX ARS Partie / 789

98 4 Domain Name Server (DNS) 4.5 F.root-servers.net (vieille version) The servers are hosted at PAIX.net, Inc. ( in Palo Alto, California and are connected to the Internet via fdx Fast Ethernet connections which are provided by UUNET ( Teleglobe ( and MFN ( For more information on the root DNS system, see : BCP 40 (RFC2870) - Operational guidelines for Root Name Servers ( c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.6 F.root-servers.net (à jour) Chapitre 4 Domain Name Server (DNS) 4.6 F.root-servers.net (à jour) (cf « 2 nœuds globaux, plus de trente nœuds locaux répartis dans divers pays. c T.Besançon (v ) Administration UNIX ARS Partie / 789

99 4 Domain Name Server (DNS) 4.7 Utilitaire rndc Chapitre 4 Domain Name Server (DNS) 4.7 Utilitaire rndc Syntaxe : rndc [options] cmd Il contrôle le fonctionnement de «named» à distance via TCP («rndc.conf» contient des clefs d accès). «status» status de NAMED «dumpdb» dumpe la base et le cache dans «/var/tmp/named_dump.db» «reload» recharge les zones primaires et secondaires «stats» dumpe les statistiques dans «/var/tmp/named.stats» «trace/notrace» gestion du niveau de trace dans «/var/tmp/named.run» «start» démarre NAMED «stop» arrête NAMED en sauvant les mises à jour en cours «halt» arrête NAMED froidement «restart» arrête et redémarre NAMED c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.8 Fichier /etc/resolv.conf Chapitre 4 Domain Name Server (DNS) 4.8 Fichier /etc/resolv.conf Consultation des nameservers indiqués via le fichier «/etc/resolv.conf» Exemple de fichier «/etc/resolv.conf» : domain formation.jussieu.fr search formation.jussieu.fr jussieu.fr nameserver nameserver Attention : Au plus 3 lignes «nameserver». Tous les UNIX ne comprennent pas la directive «search». Un commentaire commence par «;». c T.Besançon (v ) Administration UNIX ARS Partie / 789

100 4 Domain Name Server (DNS) 4.9 Interrogation manuelle DNS : nslookup Chapitre 4 Domain Name Server (DNS) 4.9 Interrogation manuelle DNS : nslookup Syntaxe : nslookup [options] à-résoudre % nslookup Server: sunars1.formation.jussieu.fr Address: Non-authoritative answer: Name: Address: La machine est dans le cache du DNS parce qu elle a déjà été résolue dans un passé récent. Cet utilitaire tombe en désuétude. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Chapitre 4 Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig C est le remplaçant de «nslookup». Il est très low level. Syntaxe : dig [options] à-résoudre Quelques flags utilisés : flag «QR» : Query flag «AA» : Authoritative Answer flag «TC» : TCP flag «RD» : Recursion Desired flag «RA» : Recursion Available flag «AD» : Authentic Data (DNSSEC) flag «CD» : Checking Disabled (DNSSEC) ID QR Opcode AA TC RD RA Z AD CD RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT c T.Besançon (v ) Administration UNIX ARS Partie / 789

101 4 Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Exemple 1 : récursivité jusqu à la racine % dig +trace ; <<>> DiG <<>> +trace ;; global options: printcmd IN NS K.ROOT-SERVERS.NET IN NS L.ROOT-SERVERS.NET IN NS M.ROOT-SERVERS.NET IN NS A.ROOT-SERVERS.NET IN NS B.ROOT-SERVERS.NET IN NS C.ROOT-SERVERS.NET IN NS D.ROOT-SERVERS.NET IN NS E.ROOT-SERVERS.NET IN NS F.ROOT-SERVERS.NET IN NS G.ROOT-SERVERS.NET IN NS H.ROOT-SERVERS.NET IN NS I.ROOT-SERVERS.NET IN NS J.ROOT-SERVERS.NET. ;; Received 244 bytes from #53( ) in 5 ms fr IN NS DNS.CS.WISC.EDU. fr IN NS NS1.NIC.fr. fr IN NS NS3.NIC.fr. fr IN NS DNS.INRIA.fr. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig fr IN NS NS2.NIC.fr. fr IN NS DNS.PRINCETON.EDU. fr IN NS NS-EXT.VIX.COM. fr IN NS NS3.DOMAIN-REGISTRY.NL. ;; Received 373 bytes from #53(K.ROOT-SERVERS.NET) in 273 ms jussieu.fr IN NS shiva.jussieu.fr. jussieu.fr IN NS cendrillon.lptl.jussieu.fr. jussieu.fr IN NS soleil.uvsq.fr. ;; Received 166 bytes from #53(DNS.CS.WISC.EDU) in 337 ms IN CNAME serveur.formation.jussieu.fr. serveur.formation.jussieu.fr IN A formation.jussieu.fr IN NS cendrillon.lptl.jussieu.fr. formation.jussieu.fr IN NS shiva.jussieu.fr. formation.jussieu.fr IN NS soleil.uvsq.fr. ;; Received 204 bytes from #53(shiva.jussieu.fr) in 217 ms On voit bien le mécanisme de consultations des différents nameservers. c T.Besançon (v ) Administration UNIX ARS Partie / 789

102 4 Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Exemple 2 : consultation à la nslookup % dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME serveur.formation.jussieu.fr. serveur.formation.jussieu.fr IN A ;; AUTHORITY SECTION: formation.jussieu.fr IN NS cendrillon.lptl.jussieu.fr. formation.jussieu.fr IN NS shiva.jussieu.fr. formation.jussieu.fr IN NS soleil.uvsq.fr. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig ;; ADDITIONAL SECTION: shiva.jussieu.fr IN A soleil.uvsq.fr IN A cendrillon.lptl.jussieu.fr IN A ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Thu Aug 29 00:22: ;; MSG SIZE rcvd: 204 c T.Besançon (v ) Administration UNIX ARS Partie / 789

103 4 Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Exemple 3 : réponse en cas d erreur % dig cerise ; <<>> DiG <<>> cerise ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cerise. IN A ;; AUTHORITY SECTION: IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM ;; Query time: 206 msec ;; SERVER: #53( ) ;; WHEN: Thu Aug 29 00:22: ;; MSG SIZE rcvd: 98 c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Exemple 4 : précision du type du record Première fois : % dig SOA ; <<>> DiG 8.2 <<>> SOA ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; type = SOA, class = IN ;; AUTHORITY SECTION: crlv.org. 2H IN SOA ns.easynet.fr. hostmaster.easynet.fr. ( ; serial 1H ; refresh 30M ; retry 4W ; expiry 2H ) ; minimum ;; Total query time: 14 msec ;; FROM: apollinaire.paris4.sorbonne.fr to SERVER: default ;; WHEN: Thu Aug 29 15:06: ;; MSG SIZE sent: 30 rcvd: 90 c T.Besançon (v ) Administration UNIX ARS Partie / 789

104 4 Domain Name Server (DNS) 4.10 Interrogation manuelle DNS : dig Deuxième fois : % dig SOA ; <<>> DiG 8.2 <<>> SOA ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; type = SOA, class = IN ;; AUTHORITY SECTION: crlv.org. 1h55m43s IN SOA ns.easynet.fr. hostmaster.easynet.fr. ( ; serial 1H ; refresh 30M ; retry 4W ; expiry 2H ) ; minimum ;; Total query time: 13 msec ;; FROM: apollinaire.paris4.sorbonne.fr to SERVER: default ;; WHEN: Thu Aug 29 15:10: ;; MSG SIZE sent: 30 rcvd: 98 c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.11 Record de type PTR Chapitre 4 Domain Name Server (DNS) 4.11 Record de type PTR On peut aussi interroger un nameserver pour résoudre des adresses : % /usr/sbin/nslookup Server: sunars1.formation.jussieu.fr Address: Name: Address: A rapprocher de : % /usr/sbin/nslookup -query=ptr in-addr.arpa Server: sunars1.formation.jussieu.fr Address: Non-authoritative answer: in-addr.arpa name = Authoritative answers can be found from: in-addr.arpa nameserver = ns1.fth.net in-addr.arpa nameserver = ns2.fth.net ns1.fth.net internet address = ns2.fth.net internet address = c T.Besançon (v ) Administration UNIX ARS Partie / 789

105 4 Domain Name Server (DNS) 4.11 Record de type PTR. fr arpa jussieu in addr formation 134 sunars Assurer la coherence 1 sunars1.formation.jussieu.fr Une faute courante : oublier de mettre à jour l entrée relative à l adresse IP de la machine. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.12 Fichier /etc/nsswitch.conf Chapitre 4 Domain Name Server (DNS) 4.12 Fichier /etc/nsswitch.conf Certains systèmes UNIX permettent de spécifier quelles méthodes de résolution utiliser (DNS, «/etc/hosts», NIS) ainsi que l ordre d enchaînement des méthodes. Sur Linux et Solaris, cf «/etc/nsswitch.conf» (voir page 552) :... hosts:... files nisplus nis dns ou... hosts:... xfn nisplus dns [NOTFOUND=return] files c T.Besançon (v ) Administration UNIX ARS Partie / 789

106 4 Domain Name Server (DNS) 4.13 Délégation d une partie de classe C Chapitre 4 Domain Name Server (DNS) 4.13 Délégation d une partie de classe C RFC 2317 « Avis : Mécanisme astucieux mais un peu compliqué à mettre en œuvre en pratique. c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.13 Délégation d une partie de classe C WebDNS Logiciel WebDNS : « Principe : générer les données via une vraie base de données avec toutes les possibilités fines associées (par exemple une personne peut avoir le droit SQL de modifier un et un seul record DNS dans la base SQL) Logiciel non réservé aux sous classes C. En utilisation sur le campus de Jussieu par exemple. Avis : Approche très tendance pour résoudre un problème de fond dans le principe du DNS lors de vrais déployements. Avis 2 : Nouvel exemple de couplage à une base de données. c T.Besançon (v ) Administration UNIX ARS Partie / 789

107 4 Domain Name Server (DNS) 4.13 Délégation d une partie de classe C Serveur Web (client PostgreSQL) HTTP/HTTPS Internet PostgreSQL DNS PostgreSQL named.boot Base de données Serveur de données (PostgreSQL) Serveur DNS (client PostgreSQL) fichiers de zones c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.14 Nom de machine : hostname Chapitre 4 Domain Name Server (DNS) 4.14 Nom de machine : hostname Caractères autorisés : cf RFC 952 et RFC 1123 En résumé : lettres majuscules lettres minuscules chiffres caractère moins «-» caractère underscore «_» « « c T.Besançon (v ) Administration UNIX ARS Partie / 789

108 4 Domain Name Server (DNS) 4.15 WHOIS Chapitre 4 Domain Name Server (DNS) 4.15 WHOIS WHOIS base de données des informations relatives à l attribution des plages d adresses IP et des noms de domaines. Exemple d un protocole Internet loupé car les implémentations ne sont pas compatibles entre elles. RFC 954, port TCP 43 Protocole exploitable par la commande «whois». Syntaxe : «whois [ -h server-whois ] adresse-ou-domaine» c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.15 WHOIS Quelques serveurs WHOIS : «rs.internic.net» «whois.nic.fr» ou via un interface WWW : « «whois.ripe.net» c T.Besançon (v ) Administration UNIX ARS Partie / 789

109 4 Domain Name Server (DNS) 4.16 (Windows : : ipconfig /displaydns, ipconfig /flushdns) Chapitre 4 Domain Name Server (DNS) 4.16 (Windows : : ipconfig /displaydns, ipconfig /flushdns) Une machine WINDOWS utilise un cache interne pour les requêtes DNS. On peut afficher le cache interne par la commande «ipconfig /displaydns». On peut purger le cache interne par la commande «ipconfig /flushdns». c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.17 Espace de confiance Chapitre 4 Domain Name Server (DNS) 4.17 Espace de confiance c T.Besançon (v ) Administration UNIX ARS Partie / 789

110 4 Domain Name Server (DNS) 4.18 Un peu de documentation Chapitre 4 Domain Name Server (DNS) 4.18 Un peu de documentation cours réseau ARS Cf « et ftp://ftp.isc.org/isc/bind/ Cf « Cf « Cf «ftp://ftp.univ-rennes1.fr/pub/reseau/dns/exemple/» RFC 2317 «Classless IN-ADDR.ARPA delegation» « «ftp://ftp.jussieu.fr/jussieu/doc/local/dnsmail.ps.z» « DNS and BIND, 4th Edition, By Paul Albitz & Cricket Liu, 4th Edition April 2001, O Reilly & Associates, Inc. 622 pages, $44.95 c T.Besançon (v ) Administration UNIX ARS Partie / Domain Name Server (DNS) 4.19 Annexe 1 Chapitre 4 Domain Name Server (DNS) 4.19 Annexe 1 Ci joint dans la version imprimée de ce cours, la liste des top level domains DNS. c T.Besançon (v ) Administration UNIX ARS Partie / 789

111 Generic top level domains http :// Generic top level domains (gtld) «.aero» Aviation «.asia» Asia «.biz» Business Organizations «.cat» Catalan language and culture «.com» Commercial «.coop» Co-Operative Organizations «.edu» Education «.gov» US Government «.info» Open TLD «.int» International Organizations «.jobs» Jobs «.mil» US Department of Defense «.mobi» Mobile devices «.museum» Museums «.name» Personal «.net» Networks «.org» Organizations «.pro» Credentialed professionals and related entities «.tel» Publishing of contact data «.travel» Travelling Country code top level domains (cctld) A «.ac» Ascension Island «.ad» Andorra «.ae» United Arab Emirates «.af» Afghanistan «.ag» Antigua and Barbuda «.ai» Anguilla «.al» Albania «.am» Armenia «.an» Netherlands Antilles «.ao» Angola «.aq» Antarctica «.ar» Argentina «.as» American Samoa «.at» Austria «.au» Australia «.aw» Aruba «.ax» Åland Islands «.az» Azerbaijan B «.ba» Bosnia and Herzegovina «.bb» Barbados «.bd» Bangladesh «.be» Belgium «.bf» Burkina Faso «.bg» Bulgaria «.bh» Bahrain «.bi» Burundi «.bj» Benin «.bm» Bermuda «.bn» Brunei Darussalam «.bo» Bolivia «.br» Brazil «.bs» Bahamas «.bt» Bhutan «.bv» Bouvet Island «.bw» Botswana «.by» Belarus «.bz» Belize C «.ca» Canada «.cc» Cocos (Keeling) Islands «.cd» Congo, Democratic republic of the (former Zaire) «.cf» Central African Republic «.cg» Congo, Republic of «.ch» Switzerland «.ci» Côte d Ivoire 1

112 «.ck» Cook Islands «.cl» Chile «.cm» Cameroon «.cn» China «.co» Colombia «.cr» Costa Rica «.cs» Czechoslovakia (former? non-existing) «.cu» Cuba «.cv» Cape Verde «.cx» Christmas Island «.cy» Cyprus «.cz» Czech Republic D «.de» Germany «.dj» Djibouti «.dk» Denmark «.dm» Dominica «.do» Dominican Republic «.dz» Algeria E «.ec» Ecuador «.ee» Estonia «.eg» Egypt «.eh» Western Sahara «.er» Eritrea «.es» Spain «.et» Ethiopia «.eu» European Union F «.fi» Finland «.fj» Fiji «.fk» Falkland Islands «.fm» Micronesia «.fo» Faroe Islands «.fr» France G «.ga» Gabon «.gb» United Kingdom «.gd» Grenada «.ge» Georgia «.gf» French Guiana «.gg» Guernsey «.gh» Ghana «.gi» Gibraltar «.gl» Greenland «.gm» Gambia «.gn» Guinea «.gp» Guadeloupe «.gq» Equatorial Guinea «.gr» Greece «.gs» South Georgia and the South Sandwich Islands «.gt» Guatemala «.gu» Guam «.gw» Guinea-Bissau «.gy» Guyana H «.hk» Hong Kong «.hm» Heard and McDonald Islands «.hn» Honduras «.hr» Croatia «.ht» Haiti «.hu» Hungary I «.id» Indonesia «.ie» Ireland «.il» Israel «.im» Isle of Man «.in» India «.io» British Indian Ocean Territory «.iq» Iraq «.ir» Iran «.is» Iceland «.it» Italia J «.je» Jersey «.jm» Jamaica «.jo» Jordan «.jp» Japan K «.ke» Kenya «.kg» Kyrgyzstan «.kh» Cambodia «.ki» Kiribati «.km» Comoros «.kn» Saint Kitts and Nevis «.kp» Korea, Democratic Peoples Republic of «.kr» Korea, Republic of «.kw» Kuwait «.ky» Cayman Islands «.kz» Kazakhstan L «.la» Lao People s Democratic Republic «.lb» Lebanon «.lc» Saint Lucia «.li» Liechtenstein «.lk» Sri Lanka «.lr» Liberia «.ls» Lesotho 2

113 «.lt» Lithuania «.lu» Luxembourg «.lv» Latvia «.ly» Libyan Arab Jamahiriya M «.ma» Morocco «.mc» Monaco «.md» Moldova «.me» Montenegro «.mg» Madagascar «.mh» Marshall Islands «.mk» Macedonia «.ml» Mali «.mm» Myanmar «.mn» Mongolia «.mo» Macau «.mp» Northern Mariana Islands «.mq» Martinique «.mr» Mauritania «.ms» Montserrat «.mt» Malta «.mu» Mauritius «.mv» Maldives «.mw» Malawi «.mx» Mexico «.my» Malaysia «.mz» Mozambique N «.na» Namibia «.nc» New Caledonia «.ne» Niger «.nf» Norfolk Island «.ng» Nigeria «.ni» Nicaragua «.nl» The Netherlands «.no» Norway «.np» Nepal «.nr» Nauru «.nu» Niue «.nz» New Zealand O «.om» Oman P «.pa» Panama «.pe» Peru «.pf» French Polynesia «.pg» Papua New Guinea «.ph» Philippines «.pk» Pakistan «.pl» Poland «.pm» St. Pierre and Miquelon «.pn» Pitcairn «.pr» Puerto Rico «.ps» Palestine «.pt» Portugal «.pw» Palau «.py» Paraguay Q «.qa» Qatar R «.re» Reunion «.ro» Romania «.rs» Serbia «.ru» Russia «.rw» Rwanda S «.sa» Saudi Arabia «.sb» Solomon Islands «.sc» Seychelles «.sd» Sudan «.se» Sweden «.sg» Singapore «.sh» St. Helena «.si» Slovenia «.sj» Svalbard and Jan Mayen Islands «.sk» Slovakia «.sl» Sierra Leone «.sm» San Marino «.sn» Senegal «.so» Somalia «.sr» Surinam «.st» Sao Tome and Principe «.su» USSR (former) «.sv» El Salvador «.sy» Syrian Arab Republic «.sz» Swaziland T «.tc» The Turks and Caicos Islands «.td» Chad «.tf» French Southern Territories «.tg» Togo «.th» Thailand «.tj» Tajikistan «.tk» Tokelau «.tl» Timor-Leste «.tm» Turkmenistan «.tn» Tunisia «.to» Tonga «.tp» East Timor «.tr» Turkey 3

114 «.tt» Trinidad and Tobago «.tv» Tuvalu «.tw» Taiwan «.tz» Tanzania U «.ua» Ukraine «.ug» Uganda «.uk» United Kingdom «.um» United States Minor Outlying Islands «.us» United States «.uy» Uruguay «.uz» Uzbekistan V «.va» Holy See (Vatican City State) «.vc» Saint Vincent and the Grenadines «.ve» Venezuela «.vg» Virgin Islands British «.vi» Virgin Islands U.S «.vn» Vietnam «.vu» Vanuatu W «.wf» Wallis and Futuna Islands «.ws» Samoa Y «.ye» Yemen «.yt» Mayotte «.yu» Yugoslavia Z «.za» South Africa «.zm» Zambia «.zr» Zaire (non-existent, see Congo) «.zw» Zimbabwe 4

115 4 Domain Name Server (DNS) 4.20 Annexe 2 Chapitre 4 Domain Name Server (DNS) 4.20 Annexe 2 Ci joint dans la version imprimée de ce cours, la RFC 2870 sur les contraintes pour un serveur de noms de la racine. c T.Besançon (v ) Administration UNIX ARS Partie / 789

116 Network Working Group Request for Comments: 2870 Obsoletes: 2010 BCP: 40 Category: Best Current Practice R. Bush Verio D. Karrenberg RIPE NCC M. Kosters Network Solutions R. Plzak SAIC June 2000 Status of this Memo Root Name Server Operational Requirements This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract As the internet becomes increasingly critical to the world s social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gtlds, cctlds, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. 1. Background The resolution of domain names on the internet is critically dependent on the proper, safe, and secure operation of the root domain name servers. Currently, these dozen or so servers are provided and operated by a very competent and trusted group of volunteers. This document does not propose to change that, but merely to provide formal guidelines so that the community understands how and why this is done. Bush, et al. Best Current Practice [Page 1] ^L

117 RFC 2870 Root Name Server Operational Requirements June The Internet Corporation for Assigned Names and Numbers (ICANN) has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards. 1.2 The root servers serve the root, aka ".", zone. Although today some of the root servers also serve some TLDs (top level domains) such as gtlds (COM, NET, ORG, etc.), infrastructural TLDs such as INT and IN ADDR.ARPA, and some cctlds (country code TLDs, e.g. SE for Sweden), this is likely to change (see 2.5). 1.3 The root servers are neither involved with nor dependent upon the whois data. 1.4 The domain name system has proven to be sufficiently robust that we are confident that the, presumably temporary, loss of most of the root servers should not significantly affect operation of the internet. 1.5 Experience has shown that the internet is quite vulnerable to incorrect data in the root zone or TLDs. Hence authentication, validation, and security of these data are of great concern. 2. The Servers Themselves The following are requirements for the technical details of the root servers themselves: 2.1 It would be short sighted of this document to specify particular hardware, operating systems, or name serving software. Variations in these areas would actually add overall robustness. 2.2 Each server MUST run software which correctly implements the IETF standards for the DNS, currently [RFC1035] [RFC2181]. While there are no formal test suites for standards compliance, the maintainers of software used on root servers are expected to take all reasonable actions to conform to the IETF s then current documented expectations. 2.3 At any time, each server MUST be able to handle a load of requests for root data which is three times the measured peak of such requests on the most loaded server in then current normal conditions. This is usually expressed in requests per second. This is intended to ensure continued operation of root services should two thirds of the servers be taken out of operation, whether by intent, accident, or malice. Bush, et al. Best Current Practice [Page 2] ^L

118 RFC 2870 Root Name Server Operational Requirements June Each root server should have sufficient connectivity to the internet to support the bandwidth needs of the above requirement. Connectivity to the internet SHOULD be as diverse as possible. Root servers SHOULD have mechanisms in place to accept IP connectivity to the root server from any internet provider delivering connectivity at their own cost. 2.5 Servers MUST provide authoritative responses only from the zones they serve. The servers MUST disable recursive lookup, forwarding, or any other function that may allow them to provide cached answers. They also MUST NOT provide secondary service for any zones other than the root and root servers.net zones. These restrictions help prevent undue load on the root servers and reduce the chance of their caching incorrect data. 2.6 Root servers MUST answer queries from any internet host, i.e. may not block root name resolution from any valid IP address, except in the case of queries causing operational problems, in which case the blocking SHOULD last only as long as the problem, and be as specific as reasonably possible. 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as "To avoid having a corruptible cache, make your server a stealth secondary for the root zone." The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. 2.8 Servers MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non zero checksum. 3. Security Considerations The servers need both physical and protocol security as well as unambiguous authentication of their responses. 3.1 Physical security MUST be ensured in a manner expected of data centers critical to a major enterprise Whether or not the overall site in which a root server is located has access control, the specific area in which the root server is located MUST have positive access control, i.e. the number of individuals permitted access to the area MUST be limited, controlled, and recorded. At a Bush, et al. Best Current Practice [Page 3] ^L

119 RFC 2870 Root Name Server Operational Requirements June 2000 minimum, control measures SHOULD be either mechanical or electronic locks. Physical security MAY be enhanced by the use of intrusion detection and motion sensors, multiple serial access points, security personnel, etc Unless there is documentable experience that the local power grid is more reliable than the MTBF of a UPS (i.e. five to ten years), power continuity for at least 48 hours MUST be assured, whether through on site batteries, on site power generation, or some combination thereof. This MUST supply the server itself, as well as the infrastructure necessary to connect the server to the internet. There MUST be procedures which ensure that power fallback mechanisms and supplies are tested no less frequently than the specifications and recommendations of the manufacturer Fire detection and/or retardation MUST be provided Provision MUST be made for rapid return to operation after a system outage. This SHOULD involve backup of systems software and configuration. But SHOULD also involve backup hardware which is pre configured and ready to take over operation, which MAY require manual procedures. 3.2 Network security should be of the level provided for critical infrastructure of a major commercial enterprise The root servers themselves MUST NOT provide services other than root name service e.g. remote internet protocols such as http, telnet, rlogin, ftp, etc. The only login accounts permitted should be for the server administrator(s). "Root" or "privileged user" access MUST NOT be permitted except through an intermediate user account. Servers MUST have a secure mechanism for remote administrative access and maintenance. Failures happen; given the 24x7 support requirement (per 4.5), there will be times when something breaks badly enough that senior wizards will have to connect remotely. Remote logins MUST be protected by a secure means that is strongly authenticated and encrypted, and sites from which remote login is allowed MUST be protected and hardened Root name servers SHOULD NOT trust other hosts, except secondary servers trusting the primary server, for matters of authentication, encryption keys, or other access or Bush, et al. Best Current Practice [Page 4] ^L

120 RFC 2870 Root Name Server Operational Requirements June 2000 security information. If a root operator uses kerberos authentication to manage access to the root server, then the associated kerberos key server MUST be protected with the same prudence as the root server itself. This applies to all related services which are trusted in any manner The LAN segment(s) on which a root server is homed MUST NOT also home crackable hosts. I.e. the LAN segments should be switched or routed so there is no possibility of masquerading. Some LAN switches aren t suitable for security purposes, there have been published attacks on their filtering. While these can often be prevented by careful configuration, extreme prudence is recommended. It is best if the LAN segment simply does not have any other hosts on it The LAN segment(s) on which a root server is homed SHOULD be separately firewalled or packet filtered to discourage network access to any port other than those needed for name service The root servers SHOULD have their clocks synchronized via NTP [RFC1305] [RFC2030] or similar mechanisms, in as secure manner as possible. For this purpose, servers and their associated firewalls SHOULD allow the root servers to be NTP clients. Root servers MUST NOT act as NTP peers or servers All attempts at intrusion or other compromise SHOULD be logged, and all such logs from all root servers SHOULD be analyzed by a cooperative security team communicating with all server operators to look for patterns, serious attempts, etc. Servers SHOULD log in GMT to facilitate log comparison Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves The server SHOULD be protected from attacks based on source routing. The server MUST NOT rely on address or name based authentication The network on which the server is homed SHOULD have in addr.arpa service. 3.3 Protocol authentication and security are required to ensure that data presented by the root servers are those created by those authorized to maintain the root zone data. Bush, et al. Best Current Practice [Page 5] ^L

121 RFC 2870 Root Name Server Operational Requirements June The root zone MUST be signed by the Internet Assigned Numbers Authority (IANA) in accordance with DNSSEC, see [RFC2535] or its replacements. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported Root servers MUST be DNSSEC capable so that queries may be authenticated by clients with security and authentication concerns. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported Transfer of the root zone between root servers MUST be authenticated and be as secure as reasonably possible. Out of band security validation of updates MUST be supported. Servers MUST use DNSSEC to authenticate root zones received from other servers. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported A hidden primary server, which only allows access by the authorized secondary root servers, MAY be used Root zone updates SHOULD only progress after a number of heuristic checks designed to detect erroneous updates have been passed. In case the update fails the tests, human intervention MUST be requested Root zone updates SHOULD normally be effective no later than 6 hours from notification of the root server operator A special procedure for emergency updates SHOULD be defined. Updates initiated by the emergency procedure SHOULD be made no later than 12 hours after notification In the advent of a critical network failure, each root server MUST have a method to update the root zone data via a medium which is delivered through an alternative, non network, path Each root MUST keep global statistics on the amount and types of queries received/answered on a daily basis. These statistics must be made available to RSSAC and RSSAC sponsored researchers to help determine how to better deploy these machines more efficiently across the Bush, et al. Best Current Practice [Page 6] ^L

122 RFC 2870 Root Name Server Operational Requirements June Communications internet. Each root MAY collect data snapshots to help determine data points such as DNS query storms, significant implementation bugs, etc. Communications and coordination between root server operators and between the operators and the IANA and ICANN are necessary. 4.1 Planned outages and other down times SHOULD be coordinated between root server operators to ensure that a significant number of the root servers are not all down at the same time. Preannouncement of planned outages also keeps other operators from wasting time wondering about any anomalies. 4.2 Root server operators SHOULD coordinate backup timing so that many servers are not off line being backed up at the same time. Backups SHOULD be frequently transferred off site. 4.3 Root server operators SHOULD exchange log files, particularly as they relate to security, loading, and other significant events. This MAY be through a central log coordination point, or MAY be informal. 4.4 Statistics as they concern usage rates, loading, and resource utilization SHOULD be exchanged between operators, and MUST be reported to the IANA for planning and reporting purposes. 4.5 Root name server administrative personnel MUST be available to provide service 24 hours a day, 7 days per week. On call personnel MAY be used to provide this service outside of normal working hours. 5. Acknowledgements The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their constructive comments. Bush, et al. Best Current Practice [Page 7] ^L

123 RFC 2870 Root Name Server Operational Requirements June References [RFC1035] Mockapetris, P., "Domain names implementation and specification", STD 13, RFC 1035, November [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July [RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March Bush, et al. Best Current Practice [Page 8] ^L

124 RFC 2870 Root Name Server Operational Requirements June Authors Addresses Randy Bush Verio, Inc Crystal Springs Bainbridge Island, WA US Phone: Daniel Karrenberg RIPE Network Coordination Centre (NCC) Singel 258 NL 1016 AB Amsterdam Netherlands Phone: Mark Kosters Network Solutions 505 Huntmar Park Drive Herndon, VA Phone: Raymond Plzak SAIC 1710 Goodridge Drive McLean, Virginia Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC Bush, et al. Best Current Practice [Page 9] ^L

125 RFC 2870 Root Name Server Operational Requirements June Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bush, et al. Best Current Practice [Page 10]

126 4 Domain Name Server (DNS) 4.21 Annexe 3 Chapitre 4 Domain Name Server (DNS) 4.21 Annexe 3 Ci joint dans la version imprimée de ce cours, un article sur les nameservers de la racine. c T.Besançon (v ) Administration UNIX ARS Partie / 789

127 Combien y a t-il vraiment de serveurs DNS racine? Stéphane Bortzmeyer <stephane+blog@bortzmeyer.org> Première rédaction de cet article le 27 Novembre Dernière mise à jour le 13 Janvier La question resurgit régulièrement dans les discussions sur la gouvernance de l Internet : combien le DNS a t-il de serveurs racine? Comme souvent avec les chiffres, tout dépend de ce qu on mesure. La marionette du gouvernement états-unien se contredit même dans sa propre propagande. En 2007, l ICANN criait bien fort qu il n y en avait pas que treize serveurs racine ( pour se moquer des critiques de son concurrent, l UIT. En 2009, dans les publications officielles de la même organisation, ils sont redevenus treize ( htm). En fait, les deux textes ont raison, car ils ne mesurent pas la même chose. Ce qui est drôle est que le texte de 2007 est très agressif, très arrogant, laissant entendre que les gens qui parlent des treize serveurs sont des ignorants, alors que la même organisation reprend ce compte deux ans après. Donc, si on veut les chiffres authentiques, il faut passer un peu de temps et mieux comprendre ce qu il y a derrière les chiffres. On peut trouver tous les détails sur le site (non officiel) ( root-servers.org/) de certains des opérateurs des serveurs racine. Le résultat : Il y a onze organisations qui gèrent un serveur racine (VeriSign, ISI, Cogent, université du Maryland, NASA, ISC, armée US, Autonomica, RIPE-NCC, ICANN et WIDE). Seulement deux sont européennes et une japonaise, toutes les autres sont états-uniennes. Changer cette liste est à peu près impossible pour des raisons politiciennes. Il n y a aucun processus pour recruter un gérant de serveur racine et aucun pour en licencier un, quelles que soient les choses étranges qu il fasse (http: // En l absence d autorité (au sens moral et politique du terme) qui puisse dire qu on va remplacer telle organisation, qui ne rend pas un service génial, par telle autre (les bons ne manquent pas), la liste n a jamais connu une seule modification depuis quinze ans, cas unique de stabilité dans l Internet. Le statu quo semble la seule solution. 1

128 2 Il y a treize noms dans la racine (treize enregistrements NS pour Name Server ), de A. root-servers.net à M.root-servers.net. Avec dig, la commande digns. vous les affichera. Déduire de ce nombre une insuffisance de la résistance de la racine aux pannes ( Il n y a que treize pauvres machines (et là on imagine un vieux serveur Dell sur son rack rack) ) serait donc erroné, ces treize serveurs ne sont pas treize machines. À noter que le nombre de treize vient de vieilles considérations sur l ancienne taille des paquets DNS, limitée à 512 octets autrefois. La limite a été étendue il y a dix ans et a été effectivement dépassée lors de l introduction des adresses IPv6 dans la racine en 2008 ( announcement-04feb08.htm) mais personne n ose prendre la responsabilité de remettre en cause ce nombre magique de treize. Il y a vingt et une adresses IP de serveurs de noms de la racine (certains n ont pas encore une adresse IPv6). Grâce à l anycast anycast, il y a cent quatre vingt neuf sites physiques différents où se trouve un serveur racine, comme celui de Prague, annoncé dans le communiqué de l ICANN ( icann.org/en/announcements/announcement-26oct09-en.htm) d octobre Un bon nombre de ces sites sont purement locaux, leurs annonces BGP ne sont pas propagées en dehors d un cercle limité et ces sites ne sont donc pas accessibles de l extérieur (par exemple, ils sont souvent limités aux opérateurs connectés à un même point d échange). Ce nombre varie souvent et dépend uniquement des décisions de chaque organisation gérant un serveur. Certaines, les plus dynamiques comme l ISC, ouvrent des sites à un rythme soutenu. Il y a un nombre inconnu de machines qui assurent ce service, certainement nettement plus de deux cents, la plupart des sites hébergeant plus qu une machine, derrière un répartiteur de charge. Si on va analyser la résistance de la racine aux pannes, le chiffre à prendre en considération dépend de la panne envisagée. Si c est la panne d un composant électronique dans un ordinateur, c est bien le nombre de machines physiques qui est le paramètre important. Si la panne est un incendie ou un tremblement de terre ( c est plutôt le nombre de sites qui compte car la panne affectera tous les serveurs situés sur le site. Enfin, si la panne est de nature organisationnelle (cas de certains serveurs racines où l organisation qui les héberge ne fait guère d efforts et ne déploie guère de moyens, voire connait des conflits internes), c est bien le chiffre de onze, le nombre d organisations, qu il faut prendre en compte pour évaluer la fiabilité de la racine. -

129 4 Domain Name Server (DNS) 4.22 Annexe 4 Chapitre 4 Domain Name Server (DNS) 4.22 Annexe 4 Ci joint dans la version imprimée de ce cours, la RFC 2606 sur les noms de domaine utilisables pour faire des tests, des maquettes, pour des machines non joignables depuis Internet. c T.Besançon (v ) Administration UNIX ARS Partie / 789

130 Network Working Group D. Eastlake Request for Comments: 2606 A. Panitz BCP: 32 June 1999 Category: Best Current Practice Status of this Memo Reserved Top Level DNS Names This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. Table of Contents 1. Introduction TLDs for Testing, & Documentation Examples Reserved Example Second Level Domain Names IANA Considerations Security Considerations...3 References...3 Authors Addresses...4 Full Copyright Statement Introduction The global Internet Domain Name System is documented in [RFC 1034, 1035, 1591] and numerous additional Requests for Comment. It defines a tree of names starting with root, ".", immediately below which are top level domain names such as ".com" and ".us". Below top level domain names there are normally additional levels of names. Eastlake & Panitz Best Current Practice [Page 1] ^L

131 RFC 2606 Reserved Top Level DNS Names June TLDs for Testing, & Documentation Examples There is a need for top level domain (TLD) names that can be used for creating names which, without fear of conflicts with current or future actual TLD names in the global DNS, can be used for private testing of existing DNS related code, examples in documentation, DNS related experimentation, invalid DNS names, or other similar uses. For example, without guidance, a site might set up some local additional unused top level domains for testing of its local DNS code and configuration. Later, these TLDs might come into actual use on the global Internet. As a result, local attempts to reference the real data in these zones could be thwarted by the local test versions. Or test or example code might be written that accesses a TLD that is in use with the thought that the test code would only be run in a restricted testbed net or the example never actually run. Later, the test code could escape from the testbed or the example be actually coded and run on the Internet. Depending on the nature of the test or example, it might be best for it to be referencing a TLD permanently reserved for such purposes. To safely satisfy these needs, four domain names are reserved as listed and described below..test.example.invalid.localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. Eastlake & Panitz Best Current Practice [Page 2] ^L

132 RFC 2606 Reserved Top Level DNS Names June 1999 example.com example.net example.org 4. IANA Considerations IANA has agreed to the four top level domain name reservations specified in this document and will reserve them for the uses indicated. 5. Security Considerations Confusion and conflict can be caused by the use of a current or future top level domain name in experimentation or testing, as an example in documentation, to indicate invalid names, or as a synonym for the loop back address. Test and experimental software can escape and end up being run against the global operational DNS. Even examples used "only" in documentation can end up being coded and released or cause conflicts due to later real use and the possible acquisition of intellectual property rights in such "example" names. The reservation of several top level domain names for these purposes will minimize such confusion and conflict. References [RFC 1034] Mockapetris, P., "Domain names concepts and facilities", STD 13, RFC 1034, November [RFC 1035] Mockapetris, P., "Domain names implementation and specification", STD 13, RFC 1035, November [RFC 1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March Eastlake & Panitz Best Current Practice [Page 3] ^L

133 RFC 2606 Reserved Top Level DNS Names June 1999 Authors Addresses Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY Phone: (h) (w) FAX: (3) Aliza R. Panitz 500 Stamford Dr. No. 310 Newark, DE USA Phone: Eastlake & Panitz Best Current Practice [Page 4] ^L

134 RFC 2606 Reserved Top Level DNS Names June 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Eastlake & Panitz Best Current Practice [Page 5]

135 4 Domain Name Server (DNS) 4.23 Annexe 5 Chapitre 4 Domain Name Server (DNS) 4.23 Annexe 5 Ci joint dans la version imprimée de ce cours, un article intitué «Pourquoi le tld local n est pas une bonne idée». c T.Besançon (v ) Administration UNIX ARS Partie / 789

136 Pourquoi le domaine de tête.local n est pas une bonne idée Stéphane Bortzmeyer <stephane+blog@bortzmeyer.org> Première rédaction de cet article le 19 Juillet html - Sur beaucoup de sites, les ressources réseaux internes ont des noms situées sous le pseudo-tld.local. Ce TLD (domaine de tête) n a pas été enregistré à cet usage et son utilisation peut apporter des mauvaises surprises. Il vaut mieux en effet utiliser un vrai nom de domaine par exemple grandeentreprise.fr ou petiteassociation.org. Si on veut séparer les ressources locales, purement internes, local.grandeentreprise. fr ou monsite.petiteassociation.org (qui tirent profit du caractère hiérarchique du DNS) conviennent également. À une époque lointaine, un nom de domaine en.com était gratuit (oui, la réservation de renault.com m avait coûté 0 e). Puis obtenir un nom de domaine était devenu très cher ou bien soumis à de pénible restrictions bureaucratiques. Mais le prix a été nettement abaissé par des acteurs comme Gandi ( chemla.org/textes/voleur.html) et les règles d enregistrement se sont souvent assouplies. Aujourd hui il est raisonnable de supposer que tout le monde a un nom de domaine, et peut l utiliser pour ses ressources internes comme pour les externes. Mais, au fait, pourquoi.local est-il une mauvaise idée? D abord, parce qu il n est nullement garanti. L ICANN pourrait le déléguer demain et ses utilisateurs seraient alors fort marris. Le RFC réserve quelques TLD à des fins de test ou de documentation et.local n en fait pas partie. Mais le problème de fond est que.local n est pas unique puisque des tas d entreprises l utilisent. Que se passera t-il en cas de fusion ou d acquisition? Si un utilisateur de.local absorbe un autre utilisateur, les conflits de noms seront fréquents (Et le cas s est souvent produit.) 1 Pour voir le RFC de numéro NNN, par exemple rfc/rfc2606.txt 1

137 2 Ce n est pas parce que ces ressources ne sont pas accessibles de l Internet qu il faut leur donner un nom qui n est pas unique. Certes, des géants états-uniens du logiciel comme Microsoft (avec son système Active Directory) ou bien Apple (avec Bonjour), utilisent ce pseudo-tld. Mais ils ne sont pas des exemples à suivre. Cette utilisation montre simplement leur peu d intérêt de la normalisation et leur tendance au «Je fais ce que je veux et tant pis pour l opinion des autres». Lors de la discussion du RFC 4795 sur LLMNR, Apple avait même tenté d obtenir la réservation de.local avec comme seul argument «Nous nous en sommes servis unilatéralement, désormais l IETF doit approuver ce choix.» -

138 4 Domain Name Server (DNS) 4.24 Annexe 6 Chapitre 4 Domain Name Server (DNS) 4.24 Annexe 6 Ci joint dans la version imprimée de ce cours, un article sur GOOGLE DNS. c T.Besançon (v ) Administration UNIX ARS Partie / 789

139 Tout le monde parle de Google DNS... Stéphane Bortzmeyer Première rédaction de cet article le 4 Décembre Dernière mise à jour le 8 Décembre Alors, je vais en faire autant. Après Google Mail, Google Docs, Google Talk, Google Wave, Google DNS ( est la dernière vedette de la blogosphère, en attendant Google Power (pour distribuer l électricité) et Google Airlines (gratuit, évidemment, pour battre les compagnies low cost low cost). Google DNS ( est un résolveur DNS ouvert, accessible à tous gratuitement. On peut l utiliser à la place des résolveurs fournis par le service informatique du réseau local, ou par le FAI. Les instructions pour cela sont disponibles chez Google (en gros, sur Unix, il suffit d éditer son /etc/resolv.conf). L adresse à indiquer, , sera certainement dans très peu de temps une des plus connues de l Internet. C était une idée marketing géniale que d utiliser une adresse simple à mémoriser (avec son alternative, ) même s il n est pas sûr que faire de l anycast anycast sur cette plage normalement allouée à Level 3 soit parfaitement conforme aux règles de l ARIN. Mais ne chipotons pas. Quel intérêt y a t-il à utiliser un résolveur DNS distinct du résolveur habituel qu on trouve sur n importe quel réseau? La seule raison valable, à mon avis, est le cas où ledit résolveur soit inexistant ou très lent (cela arrive avec certains FAI). Mais Google met en avant d autres raisons. En résumant : vitesse, sécurité et honnêteté. Commençons par la fin : contrairement à ses trois concurrents plus anciens (dont le plus connu, en raison de leur marketing agressif, est OpenDNS ( les résolveurs de Google ne sont en effet pas des menteurs ( html). Remarquons qu on est tombés très bas : ne pas mentir devient si rare que c est désormais cité comme argument commercial. % MX doesnotexist.fr... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:

140 2 On obtient bien le NXDOMAIN ( No Such Domain ), le DNS fonctionne normalement. Et la vitesse? A priori, l essentiel du temps de réponse étant dû à la latence jusqu au résolveur, Google DNS a peu de chances d être plus rapide. À l heure actuelle, Google DNS n a apparemment pas d instance en France et le serveur semble à Francfort. Mais mesurons, ne devinons pas. En utilisant qtest ( voyons, pour une machine française, trois résolveurs de son réseau local, les deux résolveurs d OpenDNS et les deux de Google DNS : % qtest -n3 "A a.gtld-servers.net" / / / Les résolveurs locaux gagnent nettement, comme prévu. Et si on compare les trois services de résolveur extérieurs : % qtest -n3 "A a.gtld-servers.net" / / / Google l emporte sur OpenDNS, non seulement en honnêteté mais aussi en vitesse. Il n y a donc vraiment aucune raison pratique d utiliser OpenDNS. (Il y a d autres mesures sérieuses, avec le même résultat, par exemple Google DNS vs OpenDNS : Google Rocks for International Users ( manu-j.com/blog/opendns-alternative-google-dns-rocks/403/) ou Divers Resolver DNS Services ( Un autre outil de mesure, certes écrit par Google mais dont le source est disponible, si vous n avez pas confiance, est l excellent Namebench ( Voyez aussi Domain Name Speed Benchmark ( (ce dernier étant spécifique à Windows). Et la sécurité? Google promet ( html) que ses résolveurs mettent en œuvre toutes les bonnes pratiques actuelles, ce qui est la moindre des choses. La seule stratégie qui aurait été différenciatrice aurait été de faire la validation DNSSEC mais Google DNS ne le fait pas. Par rapport aux résolveurs locaux utilisant les logiciels libres actuels, à jour, comme Unbound ou BIND, Google DNS n a qu un avantage, l utilisation de la variation de la casse, un hack amusant mais marginal. Parlant de sécurité, notons un petit problème : il n y a aucune authentification entre le client sur son poste de travail et Google DNS. Rien ne garantit qu on parle bien aux machines de Google. D habitude, cette sécurisation du dernier kilomètre n était pas un problème car le résolveur DNS était proche : sur le même réseau local ou en tout cas sur le même FAI. Avec Google DNS, cela cesse d être vrai et on pourrait imaginer de nombreux détournements possibles, par attaque sur le système de routage. Ces attaques pourraient être faites par un intermédiaire, ou bien par un FAI malhonnête, peu soucieux de voir ses clients partir chez Google. Pour s en protéger, il existe plusieurs solutions techniques mais aucune ne semble réaliste. Les seules solutions DNS (j exclus IPsec et compagnie) possibles sont TSIG (RFC ), 1. Pour voir le RFC de numéro NNN, par exemple rfc/rfc2845.txt -

141 3 qui repose sur un secret partagé, et est donc inutilisable pour un service public comme Google DNS, et SIG(0) (RFC 2931), que personne n a jamais déployé). Dans les deux cas, je ne crois pas qu aucun stub resolver existant (par exemple la GNU libc) ne le gère, ce qui les rend complètement irréalistes et explique pourquoi Google n offre pas ce service de sécurité. Bref, il n y a de raisons d utiliser un service de résolveurs externe que si le sien est dramatiquement défaillant. Mais, dans ce cas, quelles sont les conséquences? D abord, il y a un problème spécifique à Google : l existence d une offre très vaste couvrant à peu près tout les services Internet. Si malhonnête que soit OpenDNS, quoi qu ils fassent des données recueillies sur les utilisateurs, le fait qu ils ne gèrent qu un unique service limite les corréalations qu ils peuvent établir et donc le mal qu ils peuvent faire. Au contraire, Google, ayant une offre complète, peut établir des relations, mettre en connexion des données, et représente donc un danger potentiel plus important. Externaliser son courrier à Gmail (ou son DNS à Google DNS), est une chose. Externaliser tous ses services en est une autre. Cela revient à avoir la même entreprise qui serait à la fois votre banque, votre médecin, votre épicier et votre garagiste... Comment Google peut-il exploiter Google DNS, service gratuit? Ici, je spécule, je n ai pas d informations précises. Google peut gagner de l argent : en exploitant l information recueillie pour améliorer le moteur de recherche, en vendant cette information (les noms les plus populaires, par exemple, une information qui intéressera les domainers domainers, surtout si la réponse est NXDOMAIN, indiquant que le domaine est libre), en hébergeant, dans le futur (ce service n existe pas aujourd hui), moyennant finances, des serveurs faisant autorité, qui profiteront de la proximité du résolveur pour de meilleures performances. Google, futur hébergeur de TLD? Reconstituer la totalité d un TLD, même lorsque celui-ci ne publie pas cette information, en comptant les noms dans les requêtes et les réponses obtenues. Ou, tout simplement, s assurer que l Internet fonctionne bien, pour que les clients puissent aller voir les autres services de Google (chez certains FAI, les résolveurs DNS marchent mal, ce qui gêne sans doute Google dans son cœur de métier). -

142 4 Domain Name Server (DNS) 4.25 Annexe 7 Chapitre 4 Domain Name Server (DNS) 4.25 Annexe 7 Ci joint dans la version imprimée de ce cours, un article sur la panne du DNS de «.se». c T.Besançon (v ) Administration UNIX ARS Partie / 789

143 Un domaine de tête entier, le suédois, disparait temporairement Stéphane Bortzmeyer Première rédaction de cet article le 14 Octobre Lundi 12 octobre, vers 20h00 UTC, le domaine de tête.se a chargé la zone DNS de numéro de série qui comprenait une énorme erreur. Pendant une heure, plus aucun nom de domaine se terminant par.se ne fonctionnait. Très vite, Twitter a vu des tweets sur le sujet ( ), puis des rapports et des discussions ont commencé sur les listes de diffusion d opérateurs comme Nanog ( La cause immédiate était le manque d un point dans le fichier de zone, les enregistrement NS de la zone avaient tous un.se en trop à la fin, par exemple h.ns.se.se. En effet, dans le format standard des fichiers de zone DNS, tel qu il est défini en section 5 du RFC , un nom qui ne se termine pas par un point est complété par la nom de la zone, ici.se. Pendant la panne, on a donc pu voir : % dig +cd NS se.... ;; ANSWER SECTION: se IN NS h.ns.se.se. se IN NS g.ns.se.se Pour voir le RFC de numéro NNN, par exemple rfc/rfc1035.txt 1

144 2 Vous avez remarqué? (Moi, je ne l avais pas vu.) Un.se de trop à la fin, les noms des serveurs de noms étaient donc tous considérés comme inexistants..se avait donc disparu de l Internet, plus de Web, plus de courrier, plus de XMPP, etc. Comme quasiment toutes les interactions sur l Internet commencent par une requête DNS, plus rien ne marchait. Selon la façon dont les résolveurs remplaçaient la délégation venue de la racine (qui était correcte) par celle faisant autorité (car publiée par le domaine.se lui-même), ils arrivaient encore à résoudre les noms en.se ou pas (BIND se débrouillait mieux qu Unbound, l inverse aurait été vrai si l erreur avait été à la racine). Le problème ne concernait pas que les enregistrement NS du TLD mais aussi ceux de toutes les zones déléguées : ballou.se NS ns1.ballou.se.se NS ns2.ballou.se.se NS ns3.aname.se.se. Vers 21h00 UTC,.se a chargé la zone qui corrigeait l erreur... et en introduisait d autres, notamment des signatures DNSSEC invalides pour le SOA ( unbound-users/2009-october/ html). (Ce problème a été reconnu par le registre (http: // Tout a finalement été réparé mais la mauvaise information pouvait encore se trouver dans des caches. Pendant un certain temps, les sites en.se restaient injoignables, sauf à obtenir de votre FAI qu il redémarre son résolveur (comme conseillé par le registre ( felaktig-dns-information/), command rndcflush pour BIND). Pendant quelle durée exactement? Le TTL est de deux jours, donc j avais pensé que ce serait la durée de la panne (et c est aussi ce qu annonce le registre ( mais Jay Daley me fait remarquer à juste titre que, les noms n existant pas, c est le cache négatif (RFC 2308) qui compte et que celui-ci est de seulement deux heures pour.se. Cette panne est une des plus graves qui aient jamais affecté un domaine de tête sérieux. Aurait-elle pu être évitée? Il est évident qu il faut faire tourner des tests de validité ( net/pipermail/dns-operations/2009-october/ html) avant de publier la zone. Mais aucun test ne détecte tous les problèmes possibles. Par exemple, un outil de vérification livré avec BIND aurait pu détecter le problème : % named-checkzone example example.zone zone example/in: NS ns1.nic.example.example has no address records (A or AAAA) Mais named-checkzone a aussi des limites. Il ne positionne pas le code de retour dans le cas cidessus, par exemple (et, non, -nfail ne change rien). Et il ne marche pas si la zone est mise à jour par dynamic update (RFC 2136). Quelques leçons à en tirer : Les problèmes surviennent, donc une détection et correction rapide est primordiale, DNSSEC, pour lequel le registre suédois était pionnier, n a pas aidé. Si les données sont fausses, DNSSEC ne va pas les corriger. Garbage In, Garbage Out Garbage In, Garbage Out. Quelques articles sur le sujet : -

145 3 Sweden s Internet broken by DNS mistake ( 25E2%2580%2599s-internet-broken-by-dns-mistake/), analyse détaillée par Pingdom, I Don t Want to Say I Told You So... ( l avis d un expert, Crisis information in the modern society... ( information_in_the_mode.html), et d un autre expert, Tech glitch darkens Swedish websites ( des nouvelles par un journal suédois anglophone, Stora internetproblem f[caractère Unicode non montré 2 ]r Sverige ( inrikes/artikel_ svd) et des nouvelles pour ceux qui parlent la langue de Henning Mankell et Stieg Larsson. Le registre de.se a publié quelques mois après une étude très détaillée en anglais ( iis.se/docs/26875-svar-till-ptsv2-eng.pdf). Je dois aussi des remerciements à Jay Daley, David Blacka, Gilles Massen, Jakob Schlyter, Jelte Jansen et Olaf Kolkman pour leurs analyses et le partage d information. 2. Car trop difficile à faire afficher par LATEX -

146 4 Domain Name Server (DNS) 4.26 Annexe 8 Chapitre 4 Domain Name Server (DNS) 4.26 Annexe 8 Ci joint dans la version imprimée de ce cours, un article sur la panne du DNS de «.se». c T.Besançon (v ) Administration UNIX ARS Partie / 789

147 1 Swedish Post and Telecom Agency (PTS) Internet security division Attn: Camilla Grimelund Thomsen Box 5398 SE Stockholm Sweden Stockholm, November 12, 2009 Information regarding the disruption of the domain name system under the Swedish top-level domain.se (Your reference document number ) In a statement dated October 14, 2009, PTS requested information regarding the disruption on October 12, 2009 in the domain name system under the top-level domain.se. In its statement, PTS requested that.se submit information and account for a number of points, as presented below. 1. A full description of the circumstances regarding the disruption on October 12, 2009, which shall include the cause and scope of the disruption..se s response: In conjunction with scheduled maintenance work on the evening of Monday, October 12, 2009, a defective zone file was distributed at 9:39 p.m. The cause of the problem was a defective program update, which was not detected despite.se s test procedures and controls. The updated software was missing the trailing dot in.se. In such cases, the Bind program automatically adds.se to all domain names. This resulted in all domain names in the.se zone being changed so as to read domainname.se.se. As a result of a well-functioning monitoring system,.se immediately detected the defect, troubleshooting commenced and a new file containing DNS information (a zone file) was produced and distributed within an hour. After 30 minutes, the crisis management organisation was aware of conditions and could follow the recovery work, while working in parallel on spreading information. The cause of the incident was a number of coinciding events and circumstances, which when combined, resulted in the defective software being applied. The process leading

148 from the development to the application of new and changed software can generally be described as follows: 2 During the development process, every altered system component is tested in a separate development environment. The tests consist of manual function tests with test cases that are adapted to the system changed that occurred and shall be implemented by two independent developers. Prior to the delivery of a release, the entire integrated production system is tested using automated function tests with predefined test cases, known as pure tests. Following an approved test, the release is delivered to the commissioning organization. During the incident in question, the manual function tests performed on the concerned program modules for zone generation failed, and the test was only performed by one developer (not two, as stipulated by the procedures). The automatic tests do not encompass zone generation either, which rendered the defect more difficult to detect. The commissioning organization performs routine function tests and specific tests of the new functionality commissioned as part of the acceptance tests. These are limited to that which can be performed by way of the interactive user interfaces offered by the system. The commissioner subsequently approves the delivery and grants authorization for activation. The commissioning organization does not test the zone generation and thus did not detect the defect during this phase either. The operating organization performs an installation in a test stage pursuant to the documentation delivered by the development division. This documentation specifies the program corrections and new functions contained in the release. The document also specifies what program packages shall be installed in what server platforms and what configuration changes shall be made. In addition, the package must include instructions regarding the preparations that shall be made (such as what services are to be turned off and the temporary unplugging of surveillance), how to perform the installation (installing the package and launching services), what tests to perform following the installation and launch, and the routines for backtracking if problems arise. In addition, the commissioning organization performs a number of basic function tests to verify that the system s components are cooperating. The documentation that was delivered with the release in question did not contain any specific tests for the validity of the zone file, or any specific actions to stop zone distribution during the work. The documentation was also missing a description of the changes that were made to the zone generation program. The operation division s own routine tests do not encompass loading and testing the generated zone file to ensure its validity and thus the defect went undetected during this phase as well.

149 Activation in the production environment takes place on a scheduled and announced service occasion. On this occasion, one person from the development department must assist the responsible operations technician. Activation is carried out following the same documentation as for the test installation. 3 In this case, activation was carried out following the same documentation as in the test stage. Accordingly, no specific test of the zone file s validity was performed, nor was the scheduled zone distribution stopped. The automatic blocks that prevent unusually large changes to the zone file were deployed. Following a visual inspection of the generated data during which the missing dot was not detected, a decision was made to force the distribution of the defective zone file. Accordingly, the defective information was published via.se s slave server operator. The zone generator is a particularly critical component of.se s operations, which.se s technicians are aware of. An aggravating circumstance of the incident was that a senior system administrator had fallen acutely ill, which caused a less experienced system administrator to implement the activation of the new release. According to the applicable routines, the change should not have been implemented with only one system administrator on-site. Another contributing factor was that the system administrator who performed the change was not familiar with the specifics of how the zone signing functioned and did not have access to the machine that conducts the zone signing. Accordingly, a decision was also made to distribute a zone file with the correct information, but with an incorrect SOA signature for.se. Given the circumstances, this was the right decision and one which enabled the contamination of the cache in the name-resolver program to be stopped. 2. A description of the implications of the aforementioned disruption, such as its affect on the domain name system and the implications for various players, including name-server operators, domain-name holders and end users..se s response: Overall, the time of day, the scarce monitoring of our system,.se s crisis-management contingency, the speed at which corrections were made and our strong contacts with name-server operators in Sweden were to our advantage and resulted in the implications of the aforementioned incident being far less severe than they could have been. The defective information that was distributed resulted in complications regarding accessibility to all.se domains during the period in which the defective information was published. At the same time, the information in the name-resolver services was cached on the Internet for a certain period of time, and for many end users, everything functioned as usual. In.SE s opinion, the implications for domain-name holders and end users were mild, while efforts were required on the part of name-server operators (ISPs, registrars och web hosting providers) and probably resulted in activities in the form of trouble shooting and customer support..se has not received any formal complaints or damage claims.

150 4 The defect was successively detected and corrected during the evening, and by 1:00 a.m. on Tuesday, October 13, the.se zone was fully functioning. However, defective information remained cached in the name-resolver services, which was beyond the control of.se. Name-resolver services that requested.se domains during the period in which the defective zone was published (approximately 9:40 p.m. 10:50 p.m. CEST 1,) received failure responses that remained cached for up to one day. Requests regarding the.se zone itself, such as DNS directors and SOA posts, were cached for up to two days. Residual effects from the event could also theoretically have occurred for up to 48 hours. However, according to.se s monitoring and trouble shooting, all visible residual effects were ended as early as 24 hours later. Slightly more than an hour after the incident, an interim zone was published. The interim zone had the correct zone information but contained an invalid DNSSEC signature. Accordingly, the contamination of the cache in the name-resolver software stopped. During the period in which the interim zone was published (approximately 10:50 p.m. 00:55 a.m. CEST), Internet users mainly received the correct response, with the exception of cases in which the name resolver required SOA DNSSEC validation for.se. These situations led to request denials as well as implementation dependence. 3. Detailed description of the actions taken by.se concerning the incident. This description shall include the actions taken by.se to reduce the implications of the disruption and whether routines were in place to manage the incident and, if so, if these can be described or if a statement can be attached..se s response: One of the first actions is presented in response two above, namely the distribution of an interim zone to immediately stop the contamination of the cache in the name-resolver software. Through direct contacts with several major Swedish Internet operators, the effects of the disruption were minimized since these operators manually purged the name-resolver services caches as soon as the interim zone was published, thus avoiding the protracted effects that the matter could have resulted in..se also backtracked to a previous version of the zone generation script. Documentation is available concerning routines for the management of backtracks, incidents and more extensive crises. Incident-management routines applicable to the event concerned are described in brief as follows: The office and production operating environments are monitored and any alerts can be automatically received from.se s monitoring system or by someone reporting a defect through customer service, an emergency telephone number or . Automatic alerts are always sent SMS to.se s emergency telephone number. Depending on the nature of the warning, alerts can also be sent to other people in the organization through other channels, such as . During normal office hours, incidents are generally managed by technical operation personnel. After normal office hours, incidents are handled by on-call personnel. The party handling the alert makes an assessment 1 Central European Summer Time

151 based on the type of alert, statistics and personal inspections. When in doubt, other parties are contacted for consultation. If this occurs after normal working hours, people from the on-call group are those primarily contacted. Depending on the results of the assessment, the following functions may be contacted: - In the case of issues stemming from the distribution of zone files in which.se s partners must be notified, the on-call personnel for.se s slave server operations shall be contacted. - In the case of matters that require administrative/legal counsel, the appropriate member of.se s management shall be contacted. - In the case of security-related matters,.se s quality and security manger shall be contacted. When an incident is deemed to have the potential to lead to a crisis,.se s crisismanagement plan is activated. The crisis-management team makes a preliminary assessment of the nature of the crisis. The crisis-management team subsequently follows the instructions specified in the crisis-management plan. The crisis-management team decides what functions are to actively work with the team, taking into account the current scenario, meaning what work groups shall be drafted. Those who are not affected by the crisis return to their regular tasks. A task manager is appointed and leaves the crisis-management team to activate the crisis plan and head the operational management of the crisis. This involves assembling the resources necessary to manage the crisis, inform them of the situation and perform an analysis of the incident according to a checklist. The task manager reports the results of the analysis to the crisis-management team. During the incident on October 12, the technical personnel in question were already onsite due to scheduled maintenance work, and the cause of the event was thus promptly identified and a correction was initiated essentially immediately. Accordingly,.SE categorizes the event as a serious incident rather than a crisis situation. 4. A description of the information regarding the disruption submitted by.se to the concerned players (such as name-server operators, domain-name holders and end users) and when and how this took place. 5.SE s response: October 12 In conjunction with the activation of the crisis plan at 11:06 p.m., a number of activities were initiated including the dissemination of information. At 11:06 p.m., the security manager notifies the information manager and customer service manager of the events and tells them to prepare for contact with the press and customers, respectively. Ongoing contact with the information manager is maintained until 1:00 a.m. At 11:10 p.m.,.se s CEO contacts Aftonbladet newspaper; at 11:16 p.m., the TT news service is contacted; and at 11:45 p.m., Expressen is notified. The reasoning behind this is that the information will reach domain-name holders and end-users quicker through the media than if.se uses resources posting the information on its website.

152 6 At 11:27 p.m., the security manager notifies the crisis management team of the status of the events by . At 11:33 p.m., the CEO notifies the Board of Directors of the status of the incident by e- mail. At 12:12 a.m., the security manager notifies.se s DNS reference group, which included most major Swedish name-server operators, of the status of the incident. At 1:05 a.m., the security manager advises the crisis-management team that the problem has been resolved and announces a return to standard operations. October 13 At 7:02 a.m., internal information is distributed to notify customer service staff and other personnel. All press contact is referred to the information manager or CEO. At 7:11 a.m., brief information is provided to the Swedish Post and Telecom Agency, the supervising authority. At 8:24 a.m., information is sent to the DNS reference group list with advice on how to purge the resolvers. At 8:30 a.m., a scheduled status meeting is held with the concerned members of the crisis-management team to obtain as much information as possible, and an internal investigation headed by the security manager is initiated. At 9:31 a.m., the information is compiled in a document that is distributed internally and posted on.se s website. At 9:30 a.m., the information is sent to the SOF group by . At 9:48 a.m., brief information is sent to.se s registrars in Swedish. At 10:17 a.m., brief information is sent to.se s registrars in English. At 11:19 a.m., supplementary information is sent to PTS. October 14 Detailed information regarding the incident is posted on.se s website and sent to.se s registrars and to the DNS reference group. October 15 Detailed information regarding the incident is sent to CENTR Full Members. PTS is updated regarding the information that was sent to Registrars and DNS operators.

153 5. A description of future measures that.se plans to implement to avoid similar disruptions from occurring. 7.SE s response: The most urgent actions taken were naturally to investigate the incident on October 12. An internal investigation commenced immediately on the morning of October 13. Two separate external investigations were subsequently initiated: one technically oriented investigation and one more focused on organization, responsibilities and routines. The IT operations group was reinforced with a temporary senior operations technician. One thing we established early on is that we are lacking channels for reaching ISPs/web hosting providers and resolver operators located outside of Sweden. Therefore we have started a global improvement initiative aiming at finding forms of creating a possibility to get this kind of contact information to all the large operators around the world, if need be. We have started discussions with various parties on this issue. Furthermore,.SE has distributed a generic request to all concerned players for suggestions for internal and external improvement measures. Submitted suggestions are being compiled, analyzed and prioritized. We are working on the formulation of an action plan based on these suggested measures and those improvement proposals that have surfaced in both the internal and external inquiries. Our routines have also been tightened up. This work is being coordinated by.se s security manger. A steering group has been appointed to make decisions regarding prioritizations and establishing who is responsible for implementing actions. Specific resources have been allocated for the additional expenses caused by the incident. The incident and the management thereof eill continue to be discussed in.se s Board of Directors at a meeting on November 23. We welcome a meeting with PTS representatives if so desired, for a more comprehensive review of the actions taken and will be taken. Danny Aerts, CEO

154 4 Domain Name Server (DNS) 4.27 Annexe 9 Chapitre 4 Domain Name Server (DNS) 4.27 Annexe 9 Ci joint dans la version imprimée de ce cours, un article sur la panne du DNS de «.cn». c T.Besançon (v ) Administration UNIX ARS Partie / 789

155 La grande panne DNS de Chine de mai 2009 Stéphane Bortzmeyer Première rédaction de cet article le 6 Novembre Le 19 mai 2009, la Chine a connu sa plus grande panne de l Internet. Sur le moment, de nombreux articles ont été publiés, sans détails pratiques la plupart du temps, à part le fait qu il s agirait d un problème lié au DNS. Le 5 novembre, à la réunion OARC ( à Pékin, Ziqian Lu, de China Telecom, a fait un remarquable exposé ( workshop /ziqian_liu.pdf) détaillant les causes de la panne. C est un bel exercice de transparence, avec plein de détails techniques. Je ne suis pas sûr que les opérateurs Internet français en fassent autant, si une telle panne frappait la France. Donc, le 19 mai vers 21 h, heure locale, les téléphones se mettent à sonner : l Internet est en panne. China Telecom, mais également d autres FAI, constate à la fois que les utilisateurs se plaignent mais que le trafic a chuté considérablement. Les tuyaux ne sont donc pas surchargés, bien au contraire. En outre, le service n est pas complètement interrompu : parfois, cela marche encore un peu. En raison de la baisse du trafic, on soupçonne un problème dans le routage. Il faut un certain temps pour que quelqu un remarque ces lignes dans le journal des serveurs de noms récursifs du FAI : 19-May :21: client: warning: client #51939: recursive-clients soft limit exceeded, ab 19-May :21: client: warning: client #1151: recursive-clients soft limit exceeded, abor Et la vérité se fait jour : le problème est dans le service DNS récursif. La majorité des requêtes DNS échouent. Quelques unes passent, ce qui explique que l Internet ne semble pas complètement en panne à certains utilisateurs. Comme presque toutes les activités Internet dépendent du DNS, le trafic réseau chute. Pour résumer la panne, il y avait bien une attaque DoS mais, comme au billard, l attaque n a pas frappé directement les serveurs DNS. L attaque a touché un service très populaire, Baofeng, qui distribue de la vidéo et de la musique. Les attaquants frappent un serveur de jeux en ligne et l arrêtent. Rien d extraordinaire, ce genre de choses arrive tous les jours sur l Internet. Sauf que l attaque stoppe également certains des serveurs du domaine baofeng.com, qui partagent la même infrastructure. Et que les logiciels clients de Baofeng, devant la panne, réagissent en faisant encore plus de requêtes DNS, qui restent sans réponse. Le logiciel résolveur utilisé par tous les FAI chinois, BIND, a une limite sur le nombre de requêtes DNS récursives en attente, 1000 par défaut. En temps normal, c est largement suffisant mais, ici elle était vite remplie par les innombrables requêtes en attente des serveurs de baofeng.com. Si vous gérez un récurseur BIND, vous pouvez voir l état des requêtes en cours avec rndc : 1

156 2 % rndc status... recursive clients: 13/1900/2000 Le dernier chiffre est la limite dure au nombre de requêtes en attente (il se règle avec l option recursive-clients dans named.conf). L avant-dernier est la limite douce à partir de laquelle BIND commencera à laisser tomber des requêtes, provoquant le message ci-dessus. Le premier chiffre est le nombre de requêtes actuellement en attente. En raison du nombre de clients attendant baofeng.com, cette limite a été vite dépassée, supprimant toute résolution DNS, même pour les domaines n ayant rien à voir avec Baofeng. Pour votre récurseur, faites le calcul : prenez la différence entre la limite douce et le nombre de clients en temps normal (ici, c est , mettons 1900) et divisez là par le taux de requêtes : cela vous donnera une idée du nombre de secondes que vous pourrez tenir en cas de panne. Ici, si le taux de requêtes est de 100 par seconde (ce qui est une valeur pour un petit FAI), vous avez droit à seulement dix-neuf secondes de marge en cas de panne d un gros domaine très populaire... La plupart des récurseurs ont probablement une valeur de recursive-clients trop basse. Conclusion : si quelqu un réussit à planter tous les serveurs DNS de google.com ou ebay.com, il peut théoriquement planter tout le DNS et donc tout l Internet. Dans le cas chinois, tous les résolveurs étaient des BIND (comme c est probablement le cas dans la plupart des pays). Il n a pas été possible de tester avec d autres résolveurs comme Unbound mais rien n indique qu ils auraient fait mieux. Le choix des développeurs de BIND était d avoir un tableau de taille limitée pour les requêtes en attente. Si ce tableau était par contre dynamique, le récurseur aurait, à la place, avalé toute la mémoire du serveur. Quelques-uns des articles les moins mal informés qui ont été publiés sur cette panne : DNS Attack Downs Internet in Parts of China ( article/165319/dns_attack_downs_interne) A month after web chaos, Baofeng issues new media player ( content/month-after-web-chaos-baofeng-issues-new-media-player) Internet attack organized says Ministry ( 2009/200905/ /article_ htm) Merci à Ziqian Lu pour ses explications détaillées. -

157 Chapitre 5 SSH c T.Besançon (v ) Administration UNIX ARS Partie / SSH 5.1 Introduction Chapitre 5 SSH 5.1 Introduction Voir cours de Frédérique BONGAT. c T.Besançon (v ) Administration UNIX ARS Partie / 789

158 Chapitre 6 Courrier électronique c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.1 Composantes du système du courrier électronique Chapitre 6 Courrier électronique 6.1 Composantes du système du courrier électronique C est un système complexe dont la complexité croît sans cesse. Il a de fortes interactions avec Internet, avec les Intranets. De nombreuses implémentations sont disponibles (X400, SMTP, Microsoft Exchange, etc.). Le système est modulaire, son bon fonctionnement reposant sur des descriptions publiquement disponibles des détails des différents protocoles. c T.Besançon (v ) Administration UNIX ARS Partie / 789

159 6 Courrier électronique 6.1 Composantes du système du courrier électronique Réseau Destinataire du courrier non local Courriers à destination d un utilisateur local Transmission au facteur local MTA Distribution personnalisée MDA Boîte aux lettres Emission d un courrier Consultation des courriers MUA c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.1 Composantes du système du courrier électronique Terminologie : MTA (Mail Transfer Agent agent de routage) En fonction de l adresse de destination, il passe le message à un certain agent de transport. Plusieurs MTA existent : Sendmail, Postfix MDA (Mail Delivery Agent agent de transport) Il reçoit un message, une destination et se charge de l acheminement. Il est spécialisé dans un type d acheminement. (synonyme mailer) MUA (Mail User Agent agent utilisateur) Il sert à la composition des messages qu il envoie à l agent de routage. c T.Besançon (v ) Administration UNIX ARS Partie / 789

160 6 Courrier électronique 6.1 Composantes du système du courrier électronique Normes utilisées : RFC 822, description du format des messages RFC 821, description du protocole SMTP (Simple Mail Transfer Protocol) RFC 974, description de l interaction d un MTA avec le DNS RFC 1035 RFC 1123 Attention : documents techniques hermétiques à la lecture compliquée Cf «ftp://ftp.lip6.fr/pub/rfc/rfc/» Les problèmes de mail sont à adresser à «postmaster». Les MTA font l hypothèse que cette adresse existe. Cette adresse doit être lue par un humain. c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.2 Sendmail Chapitre 6 Courrier électronique 6.2 Sendmail SENDMAIL : Conçu en 1982, par Eric Allman (<eric@cs.berkeley.edu>) Site officiel « Principal logiciel pour router les courriers des systèmes UNIX répandus Souple, puissant Sait s adapter aux nouveaux standards (aspects multimedia) Syntaxe difficile Outils annexes simplifiant la configuration : par exemple kit jussieu «ftp://ftp.jussieu.fr/jussieu/sendmail/kit/kit tar.z» «ftp://ftp.jussieu.fr/jussieu/sendmail/kit/doc-kit ps.z c T.Besançon (v ) Administration UNIX ARS Partie / 789

161 6 Courrier électronique 6.3 Sendmail plugins : MILTER Chapitre 6 Courrier électronique 6.3 Sendmail plugins : MILTER SENDMAIL s occupe de router les mails. Donc : hors de question de compliquer le code par un antivirus hors de question de compliquer le code par un antispam hors de question de compliquer le code par... Bref, hors de question de compliquer le code par n importe quoi qui n a pas de rapport avec le routage de mails. Par contre, possibilité d interfacer SENDMAIL à des fonctionnalités externalisées grâce à l API «MILTER» fourni par les développeurs de SENDMAIL. Cf « pour de la documentation ou des plugins. c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.3 Sendmail plugins : MILTER MILTER = communication entre SENDMAIL et des programmes externes via des sockets UNIX. c T.Besançon (v ) Administration UNIX ARS Partie / 789

162 6 Courrier électronique 6.4 Postfix Chapitre 6 Courrier électronique 6.4 Postfix « Futur successeur de SENDMAIL certainement dans quelques années. Une réflexion sur SENDMAIL a conduit à écrire postfix sous une forme non monolithique. Plusieurs démons vont s occuper chacun d une tâche bien précise et n utilisent pour cela que le minimum de privilèges système limitant le risque de piratage : transport aliases.forward rewrite resolve local mailbox local "sendmail" maildrop pickup cleanup incoming active qmgr smtp Internet Internet smtpd canonical virtual deferred relocated pipe UUCP, etc. RBL access c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.4 Postfix Le fichier de configuration est une succession d affectation de valeurs à des variables. Approche radicalement différente de celle de SENDMAIL plus proche d une programmation de la configuration. Approche de postfix identique à celle du kit jussieu pour SENDMAIL (ou vice versa). Possibilité de modifier on the fly le comportement de postfix. Par exemple à l établissement d une connexion PPP ou lors de sa cloture, on peut depuis le script PPP dire à postfix d échanger les mails maintenant avec l extérieur. Avec SENDMAIL, il faudrait arrêter SENDMAIL, mettre en place une nouvelle configuration «sendmail.cf», relancer SENDMAIL, ensemble de manœuvres lourdes. c T.Besançon (v ) Administration UNIX ARS Partie / 789

163 6 Courrier électronique 6.5 Postfix plugins Chapitre 6 Courrier électronique 6.5 Postfix plugins Il existe un mécanisme à MILTER de SENDMAIL dans POSTFIX. Utilisation de sockets UNIX aussi. c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.6 Boites aux lettres : folders Chapitre 6 Courrier électronique 6.6 Boites aux lettres : folders Deux formats classiques de folders sous UNIX : folder MBOX folder MAILDIR c T.Besançon (v ) Administration UNIX ARS Partie / 789

164 6 Courrier électronique 6.7 Boites aux lettres : folder MBOX Chapitre 6 Courrier électronique 6.7 Boites aux lettres : folder MBOX Un fichier stocke tous les mails reçus du MDA et manipulés par les MUA : Classiquement «/var/mail/$username». Problèmes de verrouillage du fichier lors des lectures/écritures, de manipulation de grosses boites aux lettres, etc. c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.7 Boites aux lettres : folder MBOX Structure d un mail : From samag@neodata.com Mon Nov 19 21:27: Return-Path: <samag@neodata.com> Received: from localhost (localhost [ ]) by apollinaire.paris4.sorbonne.fr (8.11.6/8.11.6) with ESMTP id fajkrfy03543 for <Thierry.Besancon@localhost>; Mon, 19 Nov :27: (MET) Received: from sorbon.sorbonne.fr [ ] by localhost with POP3 (fetchmail-5.9.4) for Thierry.Besancon@localhost (single-drop); Mon, 19 Nov :27: (MET) Received: from neodata.com ([ ]) by sorbon.sorbonne.fr (8.11.0/jtpda-5.3.3) with ESMTP id fajkqno06486 for <Thierry.Besancon@paris4.sorbonne.fr>; Mon, 19 Nov :26: (MET) Received: from bennett (bennett.neo.comm.eds.com [ ]) by neodata.com ( Sun/8.9.1) with ESMTP id fajkrbk17328; Mon, 19 Nov :27: (MST) Received: by bennett (8.8.8+Sun/SMI-SVR4) id NAA14733; Mon, 19 Nov :26: (MST) Date: Mon, 19 Nov :26: (MST) From: samag@neodata.com X-Gnus-Mail-Source: directory:~/mail/incoming/ Message-Id: < NAA14733@bennett> To: Thierry.Besancon@paris4.sorbonne.fr Subject: NEW ORDER Suite sur transparent suivant c T.Besançon (v ) Administration UNIX ARS Partie / 789

165 6 Courrier électronique 6.7 Boites aux lettres : folder MBOX Structure d un mail (suite) : X-AntiVirus: scanned for viruses by AMaViS ( X-UIDL: Tjg!!<n*"!6i+"!J@O!! Status: RO X-Content-Length: 299 SYS ADMIN appreciates your inquiry and welcomes the opportunity to serve your needs. En résumé : une ligne commencant par «From» (attention à l espace suivant le From) autres entêtes une ligne blanche marquant la fin des entêtes et le début du corps du mail corps du mail une ligne blanche après le corps du mail c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.7 Boites aux lettres : folder MBOX Structure d un mail (suite) : Attention : si le corps du message contient une ligne commencant par «From», la ligne est transformée en «>From». Pourquoi? c T.Besançon (v ) Administration UNIX ARS Partie / 789

166 6 Courrier électronique 6.7 Boites aux lettres : folder MBOX Le format folder MBOX est manipulable par plusieurs MUA. Le MUA le plus simple pour cela est la commande «Mail» (ou «mail» ou «mailx»). % Mail "/var/mail/besancon": 4 messages 4 new >N 1 besancon@example.c Thu Aug 24 01:45 32/1175 Output from "cron" comman N 2 besancon@example.c Fri Aug 25 01:45 32/1175 Output from "cron" comman N 3 besancon@example.c Sat Aug 26 01:45 32/1175 Output from "cron" comman N 4 me@localhost.com Mon Aug 28 00:27 44/1624 Account details for besan ---> 4 From apache@example.com Mon Aug 28 00:27: Date: Mon, 28 Aug :24: (MEST) To: besancon@example.com Subject: Account details for besancon at drupal MIME-Version: 1.0 Content-transfer-encoding: 8Bit From: me@localhost.com besancon, Thank you for registering at drupal. You may now log in to username: besancon c T.Besançon (v ) Administration UNIX ARS Partie / 789 password: urm87u9efi 6 Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Chapitre 6 Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Un fichier stocke un seul mail. Plus de problème de verrouillage du fichier lors des lectures/écritures. « c T.Besançon (v ) Administration UNIX ARS Partie / 789

167 6 Courrier électronique 6.8 Boites aux lettres : folder MAILDIR En résumé : une ligne commencant par «From» (attention à l espace suivant le From) autres entêtes une ligne blanche marquant la fin des entêtes et le début du corps du mail corps du mail Attention : si le corps du message contient une ligne commencant par «From», la ligne n est pas transformée. Pourquoi? pas de ligne blanche après le corps du mail. Pourquoi? c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Comment stocker les mails au format MAILDIR? La structure d un folder MAILDIR appelé «FOLDER» implique plusieurs répertoires : «FOLDER/new» «FOLDER/cur» (cur pour current) «FOLDER/tmp» Le MDA place un nouveau mail d abord par le répertoire «FOLDER/tmp» temporairement le temps de calculer un nom de fichier unique. Le nouveau mail est ensuite placé dans le répertoire «FOLDER/new» par le MDA. La lecture d un mail entraine son déplacement de «FOLDER/new» vers «FOLDER/cur» avec ajout d un suffixe indiquant les opérations faites par le MUA sur le mail. c T.Besançon (v ) Administration UNIX ARS Partie / 789

168 6 Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Le nom du fichier stockant un mail doit être unique et en général a le format «time.pid.host». Voir : « « Par exemple : M707068P58898V0700FF01I06974E18_1.mail..example.com,S=989 :2,S avec : = temps depuis l origine en secondes ; ctime( ) = Sun Jul 29 13:28: M = compteur en microsecondes de «gettimeofday()» P58898 = process ID du MDA V0700FF01 = UNIX device number I06974E18 = UNIX inode number mail.example.com = nom de la machine UNIX du MDA S=989 = taille du mail en octets mbox:2,RS ; ici c est le résultat d une conversion par le programme MB2MD c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Après manipulation par le MUA, on ajoute un suffixe «:2,flags» avec flag : flag «P» (Passed) = mail resent/forwarded/bounced flag «R» (Replied) = mail répondu flag «S» (Seen) = mail lu flag «T» (Trashed) = mail mis à la poubelle flag «D» (Draft) = mail brouillon flag «F» (Flagged) = mail taggé pour usage ultérieur Par exemple : M707068P58898V0700FF01I06974E18_1.mail. example.com,s=989 :2,S mbox :2,RS c T.Besançon (v ) Administration UNIX ARS Partie / 789

169 6 Courrier électronique 6.8 Boites aux lettres : folder MAILDIR Possibilité de folders MAILDIR imbriqués. Par exemple : ce qui donnera sous UNIX les répertoires «.system.sa-blacklist/», «.system.sa-false-negative/», «.system.sa-false-positive/», «.system.sa-whitelist/» (avec les classiques sous-répertoires «cur», «new» et «tmp») c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.8 Boites aux lettres : folder MAILDIR On peut convertir un folder MBOX vers un folder MAILDIR : « c T.Besançon (v ) Administration UNIX ARS Partie / 789

170 6 Courrier électronique 6.9 Protocole de consultation : POP Chapitre 6 Courrier électronique 6.9 Protocole de consultation : POP SMTP Serveur de mails POP download des mails Client POP Mail folders c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.9 Protocole de consultation : POP POP Post Office Protocol ; RFC??? Port POP : 110 Port POP + SSL : 995 c T.Besançon (v ) Administration UNIX ARS Partie / 789

171 6 Courrier électronique 6.10 Protocole de consultation : IMAP Chapitre 6 Courrier électronique 6.10 Protocole de consultation : IMAP SMTP Serveur de mails Mail folders IMAP download des entetes des mails download des corps des mails sur demande Client IMAP c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.10 Protocole de consultation : IMAP RFC 2060 (protocole IMAP4rev1), RFC 2086 (ACL, extension de IMAP4), RFC 2087 (quota, extension de IMAP4) Port IMAP : 143 Port IMAP + SSL : 993 c T.Besançon (v ) Administration UNIX ARS Partie / 789

172 6 Courrier électronique 6.11 Comparaison de session POP et IMAP xxx Chapitre 6 Courrier électronique 6.11 Comparaison de session POP et IMAP xxx Comparatif de session POP et IMAP : (extrait de « % telnet pop.example.com 110 +OK POP3 server ready USER pdupont +OK Name is a valid mailbox PASS XXXXXXXX +OK Maildrop locked and ready LIST +OK scan listing follows % telnet imap.example.com 143 * OK IMAP4 server ready. LOGIN pdupont XXXXXXXX. OK User logged in. SELECT INBOX * FLAGS (Answered Flagged Draft Deleted Seen) * OK [PERMANENTFLAGS (Answered Flagged Draft Dele * 3 EXISTS * 3 RECENT * OK [UNSEEN 1] * OK [UIDVALIDITY ]. OK [READ-WRITE] Completed. UID FETCH 1:* RFC822.SIZE * 1 FETCH (UID 1425 RFC822.SIZE 169) * 2 FETCH (UID 1426 RFC822.SIZE 811) * 3 FETCH (UID 1427 RFC822.SIZE 813). OK Completed c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.11 Comparaison de session POP et IMAP xxx RETR 1 +OK Message follows Return-Path: <root@example.com> From: root@example.com To: root@example.com Subject: essai chien chapeau essai chien chapeau. DELE 1 +OK message deleted QUIT +OK Connection closed by foreign host.. UID FETCH 1425 BODY[] * 1 FETCH (FLAGS (Recent Seen) UID 1425 BODY[] 16 Return-Path: <root@example.com> From: root@example.com To: root@example.com Subject: essai chien chapeau essai chien chapeau. OK Completed. UID STORE FLAGS (Deleted) * 1 FETCH (FLAGS (Recent Deleted Seen) UID 1425). OK Completed. EXPUNGE * 1 EXPUNGE * 2 EXISTS * 2 RECENT. OK Completed. LOGOUT * BYE LOGOUT received. OK Completed Connection closed by foreign host. c T.Besançon (v ) Administration UNIX ARS Partie / 789

173 6 Courrier électronique 6.12 Antivirus Chapitre 6 Courrier électronique 6.12 Antivirus Plusieurs antivirus sont disponibles sous UNIX : CLAMAV (gratuit) ; « SOPHOS (commercial) ; « nombreux autres logiciels commerciaux c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.13 Antispam Chapitre 6 Courrier électronique 6.13 Antispam Plusieurs antispam sont disponibles sous UNIX : BOGOFILTER (gratuit) ; « DSPAM (gratuit) ; « SPAMASSASSIN (gratuit) ; « AMAVIS (gratuit) ; « nombreux autres logiciels commerciaux c T.Besançon (v ) Administration UNIX ARS Partie / 789

174 6 Courrier électronique 6.13 Antispam Humour : c T.Besançon (v ) Administration UNIX ARS Partie / Courrier électronique 6.14 Annexe 1 Chapitre 6 Courrier électronique 6.14 Annexe 1 Ci joint dans la version imprimée de ce cours, un document sur la conception d une messagerie. c T.Besançon (v ) Administration UNIX ARS Partie / 789

175 The following paper was originally published in the Proceedings of the USENIX Symposium on Internet Technologies and Systems Monterey, California, December 1997 A Highly Scalable Electronic Mail Service Using Open Systems Nick Christenson, Tim Bosserman, David Beckemeyer EarthLink Network, Inc. For more information about USENIX Association contact: 1. Phone: FAX: office@usenix.org 4. WWW URL:

176 A Highly Scalable Electronic Mail Service Using Open Systems Nick Christenson, Tim Bosserman, David Beckemeyer EarthLink Network, Inc. Information Technology Pasadena, CA Abstract is one of the most important of the Internet services. As a very large, fast growing, Internet Service Provider, EarthLink requires a robust and powerful architecture that will support rapid expansion. This paper describes such an architecture, its motivations, its future, and the diculties in implementing a service on this scale. 1 Introduction Electronic mail has a special standing in the ranks of Internet services. Of the direct services an ISP provides to its subscribers, is certainly one of the most important. As a consequence, it requires special attention to keep running as well as expected. Additionally, there are several issues that are far more problematic for than for other services. typically requires more resources than any other service. This is because the storage needs, the processing power, and the bandwidth requirements are extreme. Furthermore, there are problems regarding authentication and provisioning that are often not required for other services. Despite its criticality, little work has been made available publicly on robust, large scale electronic mail systems. The few references we have found, such as [Grubb96], have neither addressed what we consider to be the key problems, nor have they been able to scale to the capacity that we require. This isn't too surprising. Providing service for hundreds of thousands or millions of users is a problem nobody had to solve before the advent of the national or international Internet or on line service provider. Until now, none of these organizations have chosen to come forward and publish their service architecture. Additionally, the architecting of very high performance truly distributed services is still in its infancy. The issues of distributed storage and load balancing have few, if any, available solutions that are both robust enough and perform satisfactorily for our purposes. The astute reader will certainly notice that the architecture we describe here bears a great deal of similarity to what we have already described as our news service architecture [Christ97a]. This, of course, is no accident. We've found a general set of principles which we have adapted to meet the needs of both services, and many of the important issues discussed in that article are equally applicable here. In the design of any of our service architectures, we have several requirements that must be met before we would consider deployment. For , the rst of these is message integrity. It is absolutely essential that messages, once they are accepted by our system, be delivered to their proper destination intact. Second, the system must be robust. That is, in as much as is possible, the system should survive component outages gracefully. Additionally, the entire system design should minimize the number of single points of failure. Third, the system must be scalable. When EarthLink began deployment of the current architecture, in January of 1996, we had about 25; 000 subscribers. In September of 1997, EarthLink provided service for over 350; 000 subscribers with a 99.9+% service uptime record. In fact, we expect the current system to scale to well over 1; 000; 000 users without signicant alteration of the architecture as presented here. Moreover, one should be able to accomplish the scaling of any service with a minimum of outage time, preferably with none. In all cases the performance of the service must be at least adequate, and the service must be maintainable. Problems must be easily recognizable, and it should be obvious, whenever possible, what is the cause of the outage. Further, its solution should be easy to implement and, in the meantime, the impact of the outage should be small and locally conned. Finally, we would like the service architecture to be cost{eective, not just in terms of

177 equipment acquisition, but, more critically, in terms of maintenance. 2 Architecture Description There are several logically distinct components which make up the operation of EarthLink's service. The rst, which we call the \front end" of our system (front dened as the portion which receives data from the Internet) are the systems that receive mail for \username@earthlink.net". These machines are also called the SMTP machines. The second component is the POP service, the servers to which subscribers connect to retrieve their mail. These same computers also send the mail originating from our subscribers to the Internet. (At the time of this writing, EarthLink has not deployed an IMAP service.) The third component is the le servers, which do nothing except store the mailboxes, mail queues, and auxiliary les associated with the service. The fourth component is the authentication database which holds the username/password information, information on where mailboxes are stored, and data on auxiliary services to which that account mayhave subscribed. This architecture is demonstrated graphically in Figure 1 included at the end of this paper. All the servers we use in this architecture, except for the le servers, are running some avor of Unix. With the exception of our le servers and the authentication database servers, our architecture calls for all of the servers involved in our service (as well as all our other services) to be dataless. That is, each server should store on local disk its own operating system, service software, swap space, temporary le storage for nonessential data and nothing else. This allows us to add or subtract servers from service with which the Internet or our subscribers interact without aecting the data stored. 2.1 Front End Mail Exchange (MX) DNS records for earthlink.net and mail.earthlink.net point, with high preference, to a series of servers in Round Robin. These servers all run a recent version of the freely distributable stock sendmail [Allman86] as their SMTP MTA (Simple Mail Transfer Protocol, Mail Transfer Agent; see [Postel82] for details). Writing and maintaining an SMTP MTA is a dicult and expensive task. Therefore, we have geared our architecture to allow us to use sendmail without any source modication. Since sendmail typically undergoes several signicant revisions during each calendar year, it's important that we be able to use sendmail in a form as close to the stock distribution as possible, since updating a modied sendmail every few months to reect local modications would be about as time consuming as maintaining our own MTA. An electronic mail message to be delivered to \username@earthlink.net" follows the DNS MX records for earthlink.net. We maintain several machines with high precedence MX records using Round Robin DNS to distribute the load. If any of these machines become overloaded or otherwise unavailable, we maintain a single machine with a lower precedence MX record to act as a spillway. This server does not deliver directly, but it does hold it for forwarding to the rst available front end server. Our backup MX machine could easily be congured to deliver itself, but we havecho- sen not to do this to protect against the possibility of transient errors in the mailbox locking process. This way, if the locking scheme becomes overloaded, we have a server that can still accept mail on behalf of the \earthlink.net" domain. It is our intention to minimize at all times the amount of queued around the Internet for delivery to EarthLink. The key to using the stock sendmail in our architecture is to insure that the sendmail program itself attempts to do no authentication or lookup of user names. This is actually quite simple to do. One merely must remove the \w" ag in the entry for the local delivery agent in the sendmail.cf le. Even if one runs a standard authentication scheme, we've found that this modication provides a considerable performance boost if one has a large, unhashed (i.e. linear lookup) passwd le, and the service is not completely inundated with intended for non{ existent users. The portion of the mail reception service that we did modify heavily was the mail delivery agent. This is the program that receives the mail from the MTA and actually appends it to the user's mailbox. On most systems, this program is /bin/mail. The sendmail distribution provides a delivery agent called mail.local which wehave rewritten to use our authentication methods and understand howwe store mailboxes. This is a small program which hasn't changed substantially in years, so it is easy to maintain; hence, it is a better place to add knowledge about our architecture than a moving target like sendmail. In addition to authentication and mailbox location, the mail delivery agent also knows about mailbox quotas which we impose on our subscribers. If

178 the current mailbox size is over the quota for that user, the default being 10 MB, then the message is bounced back to the MTA with reason, \User npc, mailbox full." In addition to preventing resource abuse on the part of subscribers, this also helps mitigate possible damaging eects of mail bombing by malicious people on the Internet. We believe that a 10 MB quota is quite generous, especially considering over a 28.8 modem using very high quality line speeds and no network bottlenecks, one could expect to take over an hour to download the contents of a 10 MB mailbox. 2.2 POP Daemon What we call the \back end" of our architecture is a set of machines using Round Robin DNS which act as the POP servers. They are the targets of the A records, but not the MX records, for earthlink.net and mail.earthlink.net. These are the servers to which the subscribers connect to retrieve and send . If these machines receive bound for user@earthlink.net (from our subscribers, Internet machines compliant with the SMTP protocol must follow the MX records and send this message to a front end machine), these messages are redirected to our SMTP machines at the front end. The POP servers do no local delivery. They do, however, deliver directly to the Internet. We've debated the notion of having the POP servers forward mail on to yet another set of servers for Internet delivery, but have thus far elected against it. The benet to doing this would be further compartmentalization of physical server function by logical operation, which we consider to be inherently good. We'd also reduce the likelihood of POP session slowdowns in the case that a subscriber oods the server with an inordinate amount of mail to be delivered. If the POP and Internet delivery functions were separate, the POP server would expend very few resources to hand this mail o to the delivery servers, whereas it would otherwise be required to try to send and possibly queue this mail itself. On the other hand, we don't observe this being a signicant problem. Additionally, ifwe had a separate Internet delivery service within our mail architecture, we'd have to deploy an additional machine to maintain our complete N+1 redundancy to every component, at additional cost. Someday, we probably will make such a separation, but it does not seem to be justied for the presentvolume. Like the delivery agent, the POP daemon must also know about both our modied authentication system and mailbox locations. The base implementation we started with was Qualcomm's POP daemon version 2.2, although like mail.local, we have modied it substantially. In the near future, we plan to completely rewrite the POP daemon tuned for ef- ciency in our environment implementing many of the lessons learned from developments in Web server software. 2.3 Mailbox Storage On a conventional Unix platform, mailboxes are typically stored in /var/mail or /var/spool/mail. The passwd le, used to store valid user names for incoming mail and to authenticate POP connections, is usually located in /etc, and mail which cannot be delivered immediately is stored in /var/spool/mqueue. This is where our mail architecture started out as well, but we made some signicant changes as we went along. As with Usenet news, we use the Network Appliance [Hitz95] family of servers as our network le storage for essentially the same reasons: Very good performance, high reliability of the systems, easy maintenance, and the advantages provided by the WAFL lesystem [Hitz94]. Due to performance considerations, the spool is split across several le servers and each is mounted on the SMTP and POP servers as /var/mail#, where # is the number of the mount point, in single digits as of this writing. Currently, we're using version 2 of the NFS protocol. While version 3 does give some signicant performance benets, we give it all back because of the implementation of the READDIRPLUS procedure [Callag95] which prefetches attribute information on all les in that directory, whether we need them or not. Since we store a large number of les in the same directory and are only interested in operating on one of them at a time, this is signicant overhead that we don't need. On balance, for our system, the performance dierence between versions 2 and 3 of the NFS protocol is so small as to defy precise measurement. We typically change it whenever we suspect the current version might be responsible for some strange behavior we notice. The NFS version has never turned out to be the problem, so we usually leave that version in place until we feel the need to change it again in order to eliminate it as a factor in some other problem we face. Even though the Network Appliance's WAFL lesystem provides excellent protection against the performance penalties one normally encounters when there are very large numbers of les in a single

179 directory using most other le systems, there are still signicant advantages to breaking them up further. Since we have more les and require more storage and throughput than we can realize with any one le server, we need to split the spool up and provide some mechanism to locate mailboxes within this tree. So, we create a balanced hash for each mailbox over 319 possible subdirectories (the prime base of the hash) and divide these directories over the number of le servers that compose the spool. Thus, a path to a mailbox may look something like /var/mail2/00118/npc. The POP daemon and the local delivery agent are the only parts of the mail system that need to know about these locations. Once we have this mechanism for multiple locations of mailboxes in place, we are able to extend this to allow us to dynamically balance the mailboxes or expand capacity. In addition to the notion of the \proper" location of each mailbox, both mail.local and popper (the POP daemon) understand the notion of the \old" mailbox location. If the system receives for a given mailbox, mail.local checks the \proper" location for the mailbox, and if it nds it there, appends the message in the normal manner. If the mailbox isn't there, it checks the \old" location for the mailbox. If it is found there, mail.local locks the mailbox in both locations, moves it to the new location and appends the message in the normal manner. If the mailbox exists in neither place, it creates a new mailbox in the \proper" location. The POP daemon also knows this information. It looks in the \proper" location rst, and if it is not there, it consults the \old" location. In either case, it operates on the mailbox entirely in the place where it was found. Only mail.local actually moves the mailbox. We felt that it would be better to conne the mailboxmoving logic in the simpler of the two programs. Because the mailbox can only be in one of the two places and the delivery agent and POP daemon use a common locking system (described below), there's no danger of confusion as to the mailbox location. The data on what constitutes the \old" and \proper" mailbox locations are kept in the authentication database (explained below), and this information is returned to the client process when authentication information is accessed. This feature has a major benet for our mail system. This allows us to move large numbers of mailboxes around without interrupting service. For example, if we have three le servers containing mailboxes and they are either getting to be full or running out of bandwidth capacity, we can create a new mount point, /var/mail4 for instance, mount a new le server on the mail servers, create the hash value subdirectories that will reside there, and then slide a new mail.local and popper in place (POP daemon rst!) that know which of the subdirectories from each of the rst three le servers will now be housed on the fourth. Then, as mailboxes receive new mail, they are moved onto the new le server. After a few hours, days, or weeks (depending on how much of ahurry we're in), we can start a second process of individually locking and moving mailboxes independent of any other activity on the systems. Thus, we have now expanded our system without any downtime. 2.4 Authentication One thing we quickly realized is that the standard Unix authentication systems were wholly inadequate for a service of this magnitude. The rst problem one runs into is that depending on the specic operating system, one is typically conned to between 30; 000 and 65; 535 distinct user identities. Fortunately, since none of these users have shell access to these servers (or any access other than POP access), we can have a single UID own every one of these mailboxes as long as the POP daemon is careful not to grant access to other mailboxes without re{authenticating. While this postpones several problems, it isn't sucient by itself to scale as far as we'd like. First, several Unix operating systems behave quite strangely, not to mention inappropriately, when the passwd le exceeds 60; 000 lines. This isn't completely unexpected after all how many OS vendor test suites are likely to include these cases but some of these problems manifest themselves a great distance from the passwd le and, thus, can be dicult to track. Just as important, when the passwd le gets this large, the linear lookups of individual user names become expensive and time consuming. Therefore, the rst thing we did was make ahashed passwd{like le using the Berkeley NEWDB scheme [Seltze91] that both popper and mail.local would consult for authentication. This eliminated the need to carry a large passwd le and greatly increased performance of the system. A separate machine working in a tight loop continually rebuilt the hashed passwd le as the text le was continually being modied by the the new account provisioning system. The next logical extension of this was to store the passwd le in a SQL database and replace getpwnam() calls with SQL equivalents. This provides another quantum improvement. First, this

180 eliminates the necessityofcontinually rebuilding the hash le from the at le, with savings in processor and delay times for user account modication. Second, this database may be used by other applications including RADIUS [Rigney97], Usenet news, etc... Third, it's a logical place to store additional important information about that account. For example, when a username lookup by mail.local or a username/password pair is authenticated for popper, the \old" and \proper" mailbox locations are returned to the application rather than having to be stored in at les on the system or hardcoded into the respective binary. We also intend to use this database as a repository for a great deal more information, for example storing variable mailbox quotas and lists of domains from whom to refuse mail on a user by user basis, etc... Obviously, this database is critical to not only the operation of our electronic mail system, but to other components of our overall service architecture as well. If the authentication service isn't operating, electronic mail comes to a halt. Because of this, we have taken special pains to make certain that this application is always on line by using a clustered system with failover using a dual attached storage unit for the database to meet our high availability requirements. If it becomes necessary, we can still fail over to the old common hashed passwd le with only a marginal loss of functionality and performance. 2.5 File Locking In any distributed system, concurrency issues are of paramount importance. In our system, these manifest themselves in terms of le locking. It is so important, we have given the topic its own section in this paper to discuss the issues which the implementor faces. Yesterday For data stored on local disk, flock() suces to ward against two processes attempting to process the same message or modify the same mailbox at the same time. Since all of our persistent data is accessed over NFS, this presents some signicant problems for us. When using flock() on an NFS mounted le system, these calls get translated to requests via rpc.lockd. Now, lockd isn't the most robust le locking mechanism ever devised. It isn't advisable to bank on lockd working entirely as advertised. In addition to this, many systems havelockd tables too small for our purposes. We can routinely require thousands of outstanding lock requests on a given NFS mounted lesystem at any one time, and few commercial solutions have lock tables large enough and/or lock table lookup algorithms fast enough to meet our needs. Today Therefore, wherever possible, we use the le system to perform locking. This consists of requesting an open() system call to create a new (lock) le with the O EXCL ag of a le of a predetermined name, typically mailboxname.lock, in a given location, which would typically be the mail spool. In our case, in order to keep the spool directory sizes down as much as possible and performance as high as possible, we store these les on their own shared le system. This may set o alarms in the heads of those familiar with NFS. One might well ask, \How can you be certain that this is atomic on an NFS system? How do other clients know that one has locked a given le?" Recent implementations of NFS client software ignores the attribute cache on open() calls which attempt to exclusively create a new le. Note, however, that other open() calls do not ignore the attribute cache. This means that if a process's exclusive open() on the lock le succeeds, that process has successfully locked that le. This allows us to use le locking on the mailboxes, as long as we are mortally certain that all NFS clients operate in exactly the same way. One can nd both NFS v2 and v3 implementations that behave this way. It cannot be overstated how important it is to be certain that all NFS clients behave in this manner. It is always possible that the process which creates the lock will die without having the opportunity to remove it. For this reason, all processes creating locks must touch the lock les to update their attributes periodically so that if these processes die, after a certain amount of time other processes will know that an existing lock is no longer valid and can be eliminated. Therefore, we need a function that, again, will bypass the cache and be guaranteed to immediately update the attributes on the lock le. Let us suppose that one process on one NFS client has created a lock on the mailbox \npc". Let us also suppose that a process on a dierent NFS client then tried to lock that mailbox immediately afterwards and discovered the existing lock, as it must. It's always possible that the rst process has somehow died, so it's important to understand how long the second process must wait before it can assume that

181 the rst process no longer exists, at which time it can delete the lock le, lock the le itself, and perform operations on that mailbox. Again, let us suppose that all the NFS clients are set to refresh their mailbox lockevery ve minutes, and that the NFS attribute cache is set on each client to be three minutes. One scenario is for a process on client1 to successfully lock the mailbox and then have client2 immediately attempt to lock the same mailbox and fail. At this point, the information on the locked mailbox is saved for three minutes, the duration of the attribute cache, after which client2 gets the same attribute information as before, because ve minutes has not elapsed, therefore client1 has not yet refreshed the lock. At the ve minute mark, client1 refreshes the lock le using utime(), since it also bypasses the NFS cache and operates synchronously on the lock le, but client2 has not noticed because it will be looking at the attributes in its cache until the six minute mark, when its cache expires, and it can now gets the updated information. This is represented graphically in Figure 2. client1 locks mbox client2 attempts to get lock Attribute cache on client2 expires client2 gets same lock info client1 refreshes lock client 2 notices new lock minutes Figure 2 The worst case scenario is presented in Figure 3. Here we have client1 creating a lock on a mailbox and then immediately dying. Just before the lock is scheduled to be updated, client2 attempts to lock the mailbox and fails. Client2 cannot learn that the lock hasn't been updated until just before the eight minute mark, at which point it has license to remove the lock le and proceed with its actions. Unfortunately, this potentially gives us a window of eight minutes in which real users may not be able to access their mailboxes under pathological conditions. For example, if the subscriber interrupts a POP session at the wrong moment, the POP daemon on the mail server may exit without cleaning up its lock le. Further, we explain below whywe must delay even longer than this to allow for other concerns. If the le servers ever get saturated with requests, the server can seem to \disappear" to client processes for many seconds or even minutes. This can happen as part of normal subscriber growth if one does not upgrade the capacity to handle load before it is needed. In these circumstances, problems usually manifest themselves as a sudden change in performance response from acceptable to unacceptable over a very small change in load. The mathematicians would call this a catastrophic response, where \...gradually changing forces produce sudden eects." [Zeeman77] If a le server's load is near, but not at the critical point, it can be pushed over the edge by a sudden change in the prole of normal use or by a small number of malicious or negligent individuals. client1 creates lock client1 dies client2 attempts to get lock lock expires client2 learns that lock expires minutes Figure 3 It is self{evident that one wants to provide enough surplus performance to prevent small changes from breaking the performance envelope, and certainly we strive for this, yet it is not always possible. As an example, consider a two week period in August 1996 where the total volume of EarthLink was called upon to handle doubled for reasons that are still not fully understood. While not routine, these events are not uncommon in the ISP business and, because the subscriber has a much greater ability to impact service, represent a fundamental dierence between providing Internet services and, for example, providing electric power or dial tone service. In any case, when one enters into one of these catastrophic regimes, one often encounters pathologic behavior on the part of any or all of the components of the service. Client requests can come too fast for the server(s) to handle; consequently the RPC packets can get dropped before they are processed. This can result in retransmissions by multiple clients, and on top of an already saturated system, the problem is compounded.

182 Let us suppose that we have a saturated system where the client base demand is 105% of the server's capacity to deliver it over a given period of time, not counting the load put on the server because of retransmissions. Each of these clients will now retransmit their requests after a number of tenths of seconds specied by the timeo value in the /etc/vfstab or equivalent le. If this request does not receive a response, the client waits for twice timeo and retransmits again. This process is repeated until the value of the retry variable is reached. If retry is exceeded, then the client prints a message, typically \NFS server raid not responding, still trying," and continues to retry at the maximum retry value. This maximum value will never exceed 30 seconds [Stern91]. Under these conditions, we cannot achievea\steady state" condition, the amount of trac grows, quite dramatically, without bound until something breaks. If this condition were to persist for 30 minutes, at this time as much as 25% of the requests sent to the servers may be over 5 minutes old. Note that this represents a true pathological condition, it's highly unlikely that a client machine would either be able to maintain this load given the lack of responsiveness of the server, or that the client load would be constant, but we haven't yet developed our mathematical models suciently to account for all the known variables, so we're being conservative. Given these assumptions, if we are adding 2; 000; 000 new messages to our spool in a day, a half an hour of operation at this level of saturation with a lock timeout of only 5 minutes, we must expect there to be on the order of a thousand mailbox corruptions due to multiple processes proceeding to modify mailboxes on the assumption that they have exclusive access to it. This is because they have encountered expired lock les which are actually valid, the owning process just hasn't been able to get the server to ack it's update of the lock le. The mathematics behind this analysis and an in depth examination of the ramications of this will be fully explored in [Christ97b]. Therefore, it is important that our locking mechanism allow for the possibility that a client process may not be able to get their request through to the server for several minutes after the normal locking timeout window has closed. We use a lock timeout value of 15 minutes to allow for this possibility. With regard to locking, one area of concern we have is with sendmail. Current versions want to use flock() to lock les in mail queues. On our system, the depth of these queues is extreme and the number of processes that can concurrently be trying to drain them can be as high as several hundred per machine, requiring a large number of outstanding lock requests at any one time, often too many for either the client lock daemon or the le server to accommodate. Because of this, we have two choices. Either we can put the mail queues on locally attached disk, violating our stateless architecture principle and losing the benets of the WAFL le system in handling directories with large numbers of les, or we can modify sendmail to use a dierent locking mechanism, thus violating our intention to use an unmodied SMTP MTA. Fortunately, the current sendmail implementation has very modular locking code which can be easily replaced without fundamentally altering the distribution. However, we'd like any folks working on sendmail to consider allowing a preference for various locking mechanisms to be #dene'd in the source code. Tomorrow While the mailbox locking mechanism we've just described has worked satisfactorily, it is not without its drawbacks. One drawbackisthe fact that locks may be orphaned, and other clients must wait up to 15 minutes before being able to assume they are no longer valid. Another drawback is that the synchronous NFS operations we employ greatly increase the load placed on the NFS servers which hold the lock les. Therefore, we are in the process of designing and building our next generation lock management system. In accordance with our design parameters, what we really want is a distributed lock system with no single points of failure. It has to maintain state in the case of a crash or hardware failure, and it must be able to handle at least several hundred transactions per second. We tried using a SQL database for this purpose, but we were not satised with the performance. A program like a large commercial database such as this requires too much overhead to be ecient in this manner. However, we can learn from the database style locking mechanisms and, essentially, strip away those portions of the database system which we don't need to create our own lean and mean network lock server. We plan to deploy two machines clustered together around a shared RAID system to act as our lock service. If the primary machine were to suer some form of failure, the other would take over with a target transition time of less than ve seconds. We intend to deploy the same hardware conguration

183 that we use for our authentication database. All the lock requests get written to the le system using unbuered writes before they are acknowledged so that in case of machine failure there is no loss of state. The clients open up a socket to the lock daemon on the lock server and request a lock for a given mailbox, which the daemon either accepts or denies. If it is denied, the client waits for some pseudo{ random time and tries again. We project that this system will scale well into the millions of mailboxes for a single set of lock managers. To get this scheme to scale indenitely, it's a simple matter of having the clients query dierent lock servers for dierent ranges of mailbox names. 3 Operation One of our primary design goals was to deploy a system that would be cost{eective to maintain. This service accomplishes those goals in several ways. First, by centralizing authentication in a single system, we reduce the problems associated with both maintaining multiple parallel authentication systems and insuring that they are synchronized. This is a considerable overhead savings. Second, one of the key criteria in selecting the Network Appliance as our storage system was its ease of maintenance. Because its operating system has been stripped down, eliminating functionality not necessary to its operation as a le server, the server is less likely to fail and, if it does fail, it is easier to discover and remedy the problem due to the greatly reduced number of degrees of freedom presented by the operating system. Third, because the POP servers themselves are dataless, they require much less maintenance than their stateful equivalents. The only les which differ between these computers are those that contain their host names and/or IP addresses. This means that new servers can be brought online in a very short time via cloning an active server. Just as signicant, it means that since these machines contain no important persistent data (aside from the operating system), there are few reasons for system administration to log on to the system and make changes. This helps eliminate one of the arch{nemeses of distributed computing \state drift," the tendency for systems intended to be identical or nearly identical to become more and more dierent over time. At EarthLink, one of the things we do most often is to grow an existing service to accommodate more subscribers. The eorts we have made to allow this to happen easily and with a minimum of interruption contribute greatly to lowering the cost of operation. We've already explained how we use the concept of \old" and \proper" mailbox locations to scale both le system storage and bandwidth by adding additional le servers easily and with no downtime. The network implementation we're using at this time is switched FDDI, which also scales well. As we've already mentioned the POP servers are dataless and, therefore, should lack of these resources present a problem, in very little time, and again, with a minimum of eort, we can clone and deploy a new system. This results in our service being extremely scalable on short notice. We attempt to maintain N + 1 redundancy in every possible component of the system. Our data storage systems use RAID to protect against single disk failure. We keep extra data storage servers near{line in case of failure for rapid exchange with the downed system. We keep extra FDDI cards in the switch and an extra switch chassis nearby in case these components fail. We also keep one more SMTP and POP server online than loading metrics indicate is necessary. Thus, if one fails, we can pull it out of Round Robin DNS without impacting service, aside from the problems caused by the initial component failure. Additionally, we get the benet of not having to repair the failed server immediately. Instead, we can take time to ensure that everything else is in proper running order, and then we can diagnose and repair the failed server at our leisure. On top of all this, we use a monitoring system that ags problems with each component oftheservice in our Network Operations Center, which is staed 24x7x365 and contacts appropriate on{site personnel. 4 Shortcomings We consider the architecture presented above to have considerable merit as one of the better solutions available for satisfying high volume mail service. It is, of course, not without its limitations, some of which we mention here. One of the rst problems is with sendmail as an MTA. When Eric Allman developed the original sendmail, it was not envisioned that it would still be in service over fteen years later and be pushed, rewritten, and extended to the extent that it has. It is a testament to the skill of its creator and maintainer that it has performed as well as it has for this long. Nonetheless, if one were to code an SMTP MTA today,we doubt

184 anyone would want it to take the form of sendmail. Despite this, we don't see an MTA that would provide enough signicant advantages that we would want to migrate to it in the immediate future. Of course, these statements about sendmail could have been uttered ve years ago without alteration. The bottom line is that we would prefer to run an SMTP MTA that is tighter, more ecient, and has fewer potential places for security bugs to creep in, but there isn't one available that meets our needs at this time. Probably the biggest problem with our architecture is that due to the nature of NFS, when we add additional le servers to address our performance and storage needs, we end up adding multiple single points of failure. Despite the fact that the Network Appliance le servers have been quite stable and recover quickly from problems, we feel that this is not easily scalable forever. Therefore, it is our opinion that at some point we need to abandon NFS as our distributed systems protocol for something better. Our ideal protocol would be very high performance; be completely distributed and, thus, highly scalable, local failures would cause local, not global outages, and would allow for redundant storage that eliminates local single points of failure. Unfortunately, given the current state of distributed computing, it's hard enough to nd a system that adequately addresses one of these points, and nothing seems close to providing good solutions for all of them. Consequently, we are currently in the process of designing our own distributed system to accommodate our next generation architecture requirements. 5 Current Data Today, the system described here is in operation as EarthLink's core electronic mail system. At the time of this writing, this system supports about 460,000 mailboxes for over 350,000 users. The system processes, incoming and outgoing, over 13,000,000 messages each week. This means we average about 20 incoming messages each second. We average about 20 new POP connections/second and hold open about 600 concurrent active POP daemons at peak time, with spikes to over 1000 concurrent outstanding POP connections at any one time. 6 Conclusion In conclusion, we believe we have architected a mechanism to extend a standard, freely distributable, open systems system to handle from hundreds of thousands to millions of distinct accounts with a minimum of modication to the underlying components. We also believe that this system meets, to the best of our ability todeliver, the required criteria we set out in the Introduction. 7 Acknowledgments The authors of this paper are by no means the only folks who have put a lot of eort into the development and operation of this system. We wish to especially thank Jay Cai and Max Chern who did a signicant portion of the software development on this system. Thanks to Steve Dougherty and Mark Wagnon, who provided helpful comments, and to Jim Larson, who provided valuable input on the precise mathematics of packet retransmissions. Also, a great deal of thanks go to Trent Baker and his system administration team who maintain all our services: Gianni Carlo Contardo, Jason Savoy, Marty Greer, Alwin Sun, Horst Simon, Jewel Clark, Tom Hsieh, Lori Bareld, David Van Sandt, Larry Wang, Hong Zhang, and Kenny Chen. We also wish to extend a special thank{you to Scott Holstad who made many excellent editorial improvements to early versions of this paper. References [Albitz97] P. Albitz, C Liu, DNS and BIND, 2nd Ed., O'Reilly & Associates, Inc., Sebastopol, CA, 1997, p [Allman86] E. Allman, Sendmail: An Internetwork Mail Router, BSD UNIX Documentation Set, University of California, Berkeley, CA, [Callag95] B. Callaghan, B. Pawlowski, P. Stau{ bach, RFC 1813, NFS Version 3 Protocol Specication, June [Christ97a] N. Christenson, D. Beckemeyer, T. Baker, A Scalable News Architecture on a Single Spool, ;login: vol. 22 (1997), no. 3, pp. 41{45. [Christ97b] N. Christenson, J. Larson, Work in progress.

185 [Grubb96] M. Grubb, How to Get There From Here: Scaling the Enterprise{Wide Mail Infrastructure, Proceedings of the Tenth USENIX Systems Administration Conference (LISA '96), Chicago, IL, 1996, pp. 131{138. [Hitz94] D. Hitz, J. Lau, M. Malcom, File System Design for an NFS File Server Appliance, Proceedings of the 1994 Winter USENIX, San Francisco, CA, 1994, pp. 235{246. [Hitz95] D. Hitz, An NFS File Server Appliance, level3/3001.html. [Postel82] J. Postel, RFC 821, Simple Mail Transfer Protocol, August [Rigney97] C. Rigney, A. Rubens, W. Simpson, S. Willens, RFC 2058, Remote Authentication Dial In User Service (RADIUS), January [Seltze91] M. Seltzer, O. Yigit, A New Hashing Package for UNIX, Proceedings of the 1991 Winter USENIX, Dallas, TX, [Stern91] H. Stern, Managing NFS and NIS, O'Reilly & Associates, Inc., Sebastopol, CA, 1991, chapter 12. [Zeeman77] E. Zeeman, Catastrophe Theory, Selected Papers , Addison{Wesley Publishing Company, Inc., Reading, MA, 1977, p. ix.

186 SMTP Servers SMTP Auth NFS Authentication Service File Servers File Servers INTERNET Auth NFS SMTP POP Servers POP & SMTP SUBSCRIBERS Figure 1

187 Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.1 Rappel sur les connexions IP Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.1 Rappel sur les connexions IP Rappel : Une connexion IP est constituée de plusieurs éléments : une adresse IP source un numéro de port source sur la machine de départ une adresse IP de destination un numéro de port sur la machine de destination protocole TCP ou UDP Attention : Sur UNIX, la fonction C obtenant un port source < 1024 ne fonctionne que pour l UID 0. Sur Windows, la fonction C obtenant un port source < 1024 fonctionne quel que soit l UID c T.Besançon (v ) Administration UNIX ARS Partie / 789

188 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.2 Fichier /etc/services Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.2 Fichier /etc/services Le fichier «/etc/services» mentionne des triplets (numéro de port, protocole, nom du service). Le fichier «/etc/services» sert à convertir un port numérique en un nom symbolique plus parlant. Voir les fonctions C «getservbyname()», «getservbyport()», «getservent()». ATTENTION : Le fichier «/etc/services» n indique pas les services réseau activés sur la machine. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.2 Fichier /etc/services On peut obtenir un triplet officiellement pour un programme à soi auprès de l IANA « En pratique il y a 3 catégories de triplets : Les Well Known Ports sont ceux de 0 à 1023 Les Registered Ports sont ceux de 1024 à Les Dynamic and/or Private Ports sont ceux de à c T.Besançon (v ) Administration UNIX ARS Partie / 789

189 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.2 Fichier /etc/services Extrait d un fichier «/etc/services» :... chargen 19/tcp ttytst source #Character Generator chargen 19/udp ttytst source #Character Generator ftp-data 20/tcp #File Transfer [Default Data] ftp-data 20/udp #File Transfer [Default Data] ftp 21/tcp #File Transfer [Control] ftp 21/udp #File Transfer [Control] ssh 22/tcp #Secure Shell Login ssh 22/udp #Secure Shell Login telnet 23/tcp telnet 23/udp smtp 25/tcp mail #Simple Mail Transfer smtp 25/udp mail #Simple Mail Transfer... c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.3 Commandes netstat -a, netstat -an Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.3 Commandes netstat -a, netstat -an La commande «netstat -a» affiche la liste des ports ouverts sur une machine. Les noms affichés proviennent de «/etc/services» : % netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.ssh *.* LISTEN tcp *.ssh *.* LISTEN udp4 0 0 *.syslog *.* udp6 0 0 *.syslog *.* udp4 0 0 *.bootpc *.* Active UNIX domain sockets... c T.Besançon (v ) Administration UNIX ARS Partie / 789

190 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.3 Commandes netstat -a, netstat -an La commande «netstat -an» affiche la liste des ports ouverts sur une machine sans les traduire en noms via «/etc/services». Ils sont affichés sous forme numérique : % netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.22 *.* LISTEN tcp *.22 *.* LISTEN udp4 0 0 *.514 *.* udp6 0 0 *.514 *.* udp4 0 0 *.68 *.* Active UNIX domain sockets... c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.4 Gestionnaires de services réseau Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.4 Gestionnaires de services réseau Une machine UNIX offre de nombreux services accessibles par le réseau. Souvent les services réseau contactés durent peu de temps : inutile de les faire tourner en permanence (consommation de ressources) on va les activer uniquement suite à une requête On utilise alors un «gestionnaire de services» pour écouter les requêtes pour certains services réseau et lancer ces services. Plus particulièrement, le gestionnaire de services assure : l attente de connexions réseau sur certains ports le lancement des services contactés le comportement adapté au lancement de ces services c T.Besançon (v ) Administration UNIX ARS Partie / 789

191 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.4 Gestionnaires de services réseau Il existe plusieurs gestionnaires de services : programme INETD programme XINETD Autre programme TCPD : ce n est pas un gestionnaire de services c est un contrôleur de services c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.5 Gestionnaire de services réseau : INETD Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.5 Gestionnaire de services réseau : INETD Etape 1 host1.example.com host2.example.com client inetd réseau c T.Besançon (v ) Administration UNIX ARS Partie / 789

192 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.5 Gestionnaire de services réseau : INETD Etape 2 host1.example.com host2.example.com fork() client inetd exec() serveur réseau c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.5 Gestionnaire de services réseau : INETD Etape 3 host1.example.com host2.example.com client inetd serveur réseau c T.Besançon (v ) Administration UNIX ARS Partie / 789

193 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.6 INETD : fichier de configuration /etc/inetd.conf Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.6 INETD : fichier de configuration /etc/inetd.conf Le fichier «/etc/inetd.conf» est spécifique au gestionnaire de services «inetd». Son format est le suivant : # Syntax for socket-based Internet services: # service_name socket_type proto flags user server_pathname args Par exemple :... ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd... c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.6 INETD : fichier de configuration /etc/inetd.conf La signification des champs est la suivante : champ 1 : «service_name» C est le nom symbolique d un service (cf «/etc/services»). champ 2 : «socket_type» C est le type du socket réseau. C est essentiellement «stream», «dgram». champ 3 : «proto» C est le protocole réseau utilisé : «tcp», «udp» champ 4 : «flags» Cela indique si l on peut répondre à une requête du même type alors que la première n est pas terminée. On peut avoir : «wait», «nowait» champ 5 : «user» Nom de l utilisateur sous lequel le programme tournera. champ 6 : «server_pathname» C est le chemin absolu du programme à exécuter. champ 7 : «args» Ce sont les paramètres à donner lors du «execv()». c T.Besançon (v ) Administration UNIX ARS Partie / 789

194 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.6 INETD : fichier de configuration /etc/inetd.conf Par exemple : ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l donnera execv("/usr/sbin/in.ftpd", "in.ftpd", "-l", 0); c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.7 INETD : reconfiguration via SIGHUP Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.7 INETD : reconfiguration via SIGHUP Inetd est lancé par les scripts de démarrage. Si l on modifie le fichier «/etc/inetd.conf», la modification est prise en compte en envoyant le signal «SIGHUP» au processus inetd : # ps -ax grep inetd 173? IW 2 0:00 inetd p2 S 2 0:00 grep inetd # kill -HUP 173 c T.Besançon (v ) Administration UNIX ARS Partie / 789

195 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.8 INETD : problèmes Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.8 INETD : problèmes INETD fonctionne très bien en pratique. Il a un seul gros défaut : il ne gère aucun aspect de sécurité. On aimerait au moins : pouvoir filtrer l accès à certains services avoir des traces d activation de certains services Un remède : emploi du logiciel TCP WRAPPERS « « c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS L idée de TCP WRAPPERS : on va s intercaler dans la chaîne de INETD. host1.example.com host2.example.com client inetd réseau c T.Besançon (v ) Administration UNIX ARS Partie / 789

196 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS host1.example.com host2.example.com client inetd fork() exec() tcpd réseau c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS host1.example.com host2.example.com client inetd tcpd réseau c T.Besançon (v ) Administration UNIX ARS Partie / 789

197 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS host1.example.com client host2.example.com fork() exec() inetd tcpd serveur réseau c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS host1.example.com host2.example.com client inetd tcpd serveur réseau c T.Besançon (v ) Administration UNIX ARS Partie / 789

198 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS host1.example.com host2.example.com client inetd serveur réseau c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.9 Gestionnaire de services réseau : TCP WRAPPERS La librairie des TCP WRAPPERS est maintenant intégrée à beaucoup de produits (même sous WINDOWS...). c T.Besançon (v ) Administration UNIX ARS Partie / 789

199 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.10 TCP WRAPPERS : modifications de /etc/inetd.conf Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.10 TCP WRAPPERS : modifications de /etc/inetd.conf S intercaler dans la chaîne de INETD nécessite de modifier le fichier «/etc/inetd.conf» Par exemple on passe de : ftp stream tcp nowait root /usr/etc/in.ftpd in.ftpd -l telnet stream tcp nowait root /usr/etc/in.telnetd in.telnetd shell stream tcp nowait root /usr/etc/in.rshd in.rshd login stream tcp nowait root /usr/etc/in.rlogind in.rlogind à ftp stream tcp nowait root /chemin/vers/tcpd in.ftpd -l telnet stream tcp nowait root /chemin/vers/tcpd in.telnetd shell stream tcp nowait root /chemin/vers/tcpd in.rshd login stream tcp nowait root /chemin/vers/tcpd in.rlogind c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.10 TCP WRAPPERS : modifications de /etc/inetd.conf Rappel sur l interprétation d une ligne de «inetd.conf» : Par exemple : ftp stream tcp nowait root /chemin/vers/tcpd in.ftpd -l donnera execv("/chemin/vers/tcpd", "in.ftpd", "-l", 0); c T.Besançon (v ) Administration UNIX ARS Partie / 789

200 7 Gestionnaires de services réseau : inetd, tcpd, xinetd7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny Le principe du contrôle d accès des TCP WRAPPERS repose sur les fichiers «/etc/hosts.allow» et «/etc/hosts.deny» : 1 On vérifie d abord si la requête TCP est autorisée par le contenu de «/etc/hosts.allow». Si oui, OK. Si non, on passe à l étape 2. 2 On vérifie si la requête TCP est interdite par le contenu de «/etc/hosts.deny». Si oui, la requête est rejetée. Si non, on passe à l étape 3. 3 On accepte la requête TCP. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny Au niveau des fichiers «hosts.allow» et «hosts.deny», on peut appliquer des règles de filtrage par service servi. Voici un exemple de politique de connexion : au niveau du fichier «/etc/hosts.allow» : in.telnetd:.fr, in.rlogind:.fr, in.rshd:.fr au niveau du fichier «/etc/hosts.deny» : in.telnetd: in.rlogind: in.rshd: ALL ALL ALL En français intelligible, ces fichiers indiquent que les connexions telnet, rlogin, rsh ne sont autorisées que depuis des machines du domaine français «.fr» et depuis un domaine de Tunisie (réseau d adresse ). c T.Besançon (v ) Administration UNIX ARS Partie / 789

201 7 Gestionnaires de services réseau : inetd, tcpd, xinetd7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny Une seconde syntaxe existe pour TCPD. Utiliser cette syntaxe! Syntaxe : «service : designation-machines : allow» «service : designation-machines : deny» La désignation des machines peut se faire de diverses façons : noms de machines («serveur.example.com») réseaux de noms de machines («.example.com») adresses CIDR de réseaux (« / ») adresses de réseaux (« ») nom spécial : «ALL» Nom de service spécial : «ALL» Tout autoriser : «ALL : ALL : allow» Tout interdire : «ALL : ALL : deny» c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny ATTENTION : quand on interdit une machine, il faut l interdire via son nom FQDN et via son adresse IP (pour le cas où un nameserver serait injoignable on peut ainsi bloquer quand même la machine). c T.Besançon (v ) Administration UNIX ARS Partie / 789

202 7 Gestionnaires de services réseau : inetd, tcpd, xinetd7.11 TCP WRAPPERS : contrôle d accès, /etc/hosts.allow, /etc/hosts.deny ATTENTION : Ce n est par parce que l on active tcpd que l on a résolu tous les problèmes de sécurité et que l on est tranquille! Il ne faut pas oublier que plein d autres services ne passent pas par l intermédiaire de inetd.conf Il faut surveiller les traces de fonctionnement renvoyées par tcpd. Il faut renseigner les fichiers hosts.allow et /etc/hosts.deny. Il faut des démons sans trou de sécurité. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.12 TCP WRAPPERS : programmation via libwrap.a Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.12 TCP WRAPPERS : programmation via libwrap.a Les TCP WRAPPERS offrent aussi leur librairie de programmation : «libwrap.a» et «tcpd.h» Généralement installée en «/usr/local/lib/libwrap.a» et «/usr/local/include/tcpd.h» La librairie apporte la fonction C «host_access()» On linkera avec cette librairie quand c est nécessaire. c T.Besançon (v ) Administration UNIX ARS Partie / 789

203 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.13 Gestionnaire de services réseau : XINETD Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.13 Gestionnaire de services réseau : XINETD (en anglais extended inetd) Cf « Numérotation des versions un peu compliquée... XINETD est une réécriture complète de INETD en incorporant plusieurs aspects manquants dans INETD : contrôle d accès à la TCP WRAPPERS accès horaires aux démons traces syslog des connexions (échouées, abouties) limitation du nombre d instances de chaque démon binding sur certaines adresses réseau c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.14 XINETD : fichier de configuration /etc/xinetd.conf Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, 7.14 XINETD : fichier de configuration /etc/xinetd.conf XINETD utilise le fichier «/etc/xinetd.conf», incompatible avec «/etc/inetd.conf». Format du fichier : defaults { attribut operateur valeur(s)... } service toto { attribut operateur valeur(s)... } Les opérateurs sont «=», «+=» et «-=». Cf la documentation pour la liste complète des attributs. c T.Besançon (v ) Administration UNIX ARS Partie / 789

204 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.14 XINETD : fichier de configuration /etc/xinetd.conf A noter avec certaines versions de «xinetd» la possibilité d avoir un répertoire «/etc/xinetd.d» dans lequel on trouve un fichier par service, portant le nom du service et contenant le réglage du service. Par exemple «/etc/xinetd.d/ftpd» c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.15 XINETD : réglages par défaut Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.15 XINETD : réglages par défaut Par exemple : defaults { instances = 15 log_type = FILE /var/log/servicelog log_on_success = HOST PID USERID DURATION EXIT log_on_failure = HOST USERID RECORD only_from = disabled = shell login exec comsat telnet ftp tftp finger disabled += time daytime chargen servers services xadmin } Ici la ligne «only_from =» interdit par défaut toutes les machines à se connecter aux services. On autorisera ce qui est nécessaire au niveau du bloc de configuration de chaque service. c T.Besançon (v ) Administration UNIX ARS Partie / 789

205 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.16 XINETD : configuration d un service Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.16 XINETD : configuration d un service Exemple pour le service «ftp» (cf «/etc/services») : service ftp { socket-type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l instances = 4 access_times = 7:00-12:30 13:30-21:00 nice = 10 only_from = /24 } c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.17 XINETD : /etc/xinetd.conf : directive nice Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.17 XINETD : /etc/xinetd.conf : directive nice Par exemple : service ftp { socket-type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l instances = 4 access_times = 7:00-12:30 13:30-21:00 nice = 10 only_from = /24 } c T.Besançon (v ) Administration UNIX ARS Partie / 789

206 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.18 XINETD /etc/xinetd.conf : directive access_times Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.18 XINETD : /etc/xinetd.conf : directive access_times Par exemple : service ftp { socket-type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l instances = 4 access_times = 7:00-12:30 13:30-21:00 nice = 10 only_from = /24 } c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.19 XINETD : /etc/xinetd.conf : directives bind, id Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.19 XINETD : /etc/xinetd.conf : directives bind, id Soit une machine avec 2 interfaces réseau d adresses « » et « » : service ftp { id = ftp-public bind = socket-type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l instances = 4 access_times = 7:00-21:00 nice = 10 only_from = /24 } service ftp { id = ftp-private bind = socket-type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l instances = 4 access_times = 7:00-21:00 nice = 10 only_from = /24 } La directive «id» servira au niveau de SYSLOG à différencier les traces de l un ou l autre de FTPD. c T.Besançon (v ) Administration UNIX ARS Partie / 789

207 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.20 XINETD : /etc/xinetd.conf : directive redirect Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.20 XINETD : /etc/xinetd.conf : directive redirect Par exemple : service telnet { flags = REUSE socket-type = stream wait = no user = root server = /usr/sbin/in.telnetd only_from = /24 redirect = } Et un «telnet» vers « » renverra vers le démon «telnetd» de « ». c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.21 XINETD : /etc/xinetd.conf : et directive NAMEINARGS Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.21 XINETD : /etc/xinetd.conf : tcpd et directive NAMEINARGS Par exemple : service ftp { flags = NAMEINARGS REUSE socket-type = stream wait = no user = root server = /usr/sbin/tcpd server_args = /usr/sbin/in.ftpd -l instances = 4 access_times = 7:00-12:30 13:30-21:00 nice = 10 only_from = /24 } TCP WRAPPERS et XINETD ne sont pas antinomiques. c T.Besançon (v ) Administration UNIX ARS Partie / 789

208 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.22 XINETD : /etc/xinetd.conf : directive chroot Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.22 XINETD : /etc/xinetd.conf : directive chroot Par exemple : service ftp { socket-type = stream wait = no user = root server = /usr/sbin/chroot server_args = /quelquepart/blockhaus/ftp /usr/sbin/in.ftpd -l instances = 4 access_times = 7:00-12:30 13:30-21:00 nice = 10 only_from = /24 } On est ainsi compartimenté à l arborescence de «/quelquepart/blockhaus/ftp» dont on ne peut pas sortir. Intérêt pour la sécurité de la machine. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.23 XINETD : reconfiguration, signaux Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.23 XINETD : reconfiguration, signaux Sont supportés les signaux : signal «SIGHUP» : sur sa réception, «xinetd» se reconfigure signal «SIGTERM» : sur sa réception, «xinetd» se saborde signal «SIGUSR1» : sur sa réception, «xinetd» écrit le fichier «/var/run/xinetd.dump» c T.Besançon (v ) Administration UNIX ARS Partie / 789

209 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.24 Services internes inutiles Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.24 Services internes inutiles Rappel : INETD et XINETD lancent des services réseau sur demande Exemple avec INETD : extrait de «/etc/inetd.conf» : ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l donnera execv("/usr/sbin/in.ftpd", "in.ftpd", "-l", 0); Le service est fourni par un exécutable «externe». Mais le service peut être interne et être fourni directement par INETD ou XINETD. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.24 Services internes inutiles Règle fondamentale : tous les services internes sont inutiles et doivent être désactivés. Par exemple, pour INETD : désactiver tous les services de type internal dans «/etc/inetd.conf» : #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal c T.Besançon (v ) Administration UNIX ARS Partie / 789

210 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.25 R-Services Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.25 R-Services Plusieurs services lancés par INETD et XINETD sont connus sous le nom de R-services (remote services) : service RLOGIND : connexion interactive à un système distant service RSHD : lancement d une commande sur un système distant service RCPD : recopie de fichiers locaux vers des fichiers distants ou vice-versa c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin (en anglais remote login daemon, remote login) En général, le R-service a pour chemin : «/usr/sbin/in.rlogind» ou «/usr/sbin/rlogind». Syntaxe de la R-commande : rlogin [-l user] nom-de-machine % rlogin -l besancon serveur.example.com Password: XXXXXXXX Last login: Mon Sep 15 09:42:58 from Sun Microsystems Inc. SunOS 5.5 Generic November 1995 server% A chaque fois que ce sera possible, préférer une connexion en SSH (ici avec «ssh»). c T.Besançon (v ) Administration UNIX ARS Partie / 789

211 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Contrôles d accès (1) Deux fichiers contrôlent les accès : fichier système «/etc/hosts.equiv» fichier personnel «$HOME/.rhosts» Syntaxe commune aux deux fichiers : format 1 : «hostname» format 2 : «hostname username» Deux cas de figure lors d une connexion : une ligne à l un des deux formats autorise la connexion et la connexion se fait alors sans demande de mot de passe aucune ligne n autorise la connexion et il y a alors demande du mot de passe de l utilisateur local c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Possibilité de mettre «+» à la place de n importe quel champ : signification «n importe quelle machine» signification «n importe quel utilisateur» Voir fonction C «ruserok()». c T.Besançon (v ) Administration UNIX ARS Partie / 789

212 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Contrôles d accès (2) : Format «hostname» Signification : les utilisateurs de la machine «hostname» sont autorisés à se connecter au système sous le même nom sans demande de mot de passe. Ce format est utilisable dans «/etc/hosts.equiv» et dans les fichiers personnels «$HOME/.rhosts». c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Par exemple, si le fichier «/etc/hosts.equiv» contient : cerise.example.com cela permet à un utilisateur «martin» de se connecter en RLOGIN depuis la machine «cerise.example.com» sous l identité locale «martin» sans demande de mot de passe. Par exemple, si l utilisateur «jean» a le fichier «$HOME/.rhosts» suivant : cerise.example.com cela permet à l utilisateur «jean» de se connecter en RLOGIN depuis la machine «cerise.example.com» sous l identité locale «jean» sans demande de mot de passe. c T.Besançon (v ) Administration UNIX ARS Partie / 789

213 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Contrôles d accès (3) : Format «hostname username» Signification : l utilisateur «username» de la machine «hostname» est autorisé à se connecter au système sans demande de mot de passe. Si ce format est utilisé dans «$HOME/.rhosts», alors cela autorise un utilisateur distant à se connecter sous le nom d un utilisateur local. Si ce format est utilisé dans «/etc/hosts.equiv» alors cela autorise un utilisateur distant à se connecter sous le nom de n importe quel utilisateur local. c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Par exemple, si l utilisateur «jean» a le fichier «$HOME/.rhosts» suivant : cerise.example.com martin cela permet à l utilisateur «martin» de se connecter en RLOGIN depuis la machine «cerise.example.com» sous l identité locale «jean» sans demande de mot de passe. Par exemple, si le fichier «/etc/hosts.equiv» contient : cerise.example.com jean cela permet à l utilisateur «jean» de se connecter en RLOGIN depuis la machine «cerise.example.com» sous n importe quelle identité locale sans demande de mot de passe. DANGEREUX. c T.Besançon (v ) Administration UNIX ARS Partie / 789

214 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.26 R-service rlogind, R-commande rlogin Problèmes : Attention au contenu de «/etc/hosts.equiv». SunOS 4.x.y fournissait un fichier contenant «+ +». Attention aux connexions root via le réseau. Il faut interdire les connexions root via le réseau parce qu elles sont anonymes. Vérifier «/etc/ttys» (ou équivalent «/etc/securettys»...) et minimaliser le nombre de terminaux sécurisés. Vérifier «~root/.rhosts». C est une cible privilégiée des pirates qui essayent d y écrire «+ +». Il n y a pas de traces des connexions locales. Au mieux, tcpd informe d où vient la connexion mais pas de l identité prise sur la machine locale. Remède : utiliser le package logiciel logdaemon URL «ftp://ftp.porcupine.org/pub/security/logdaemon-5.8.tar.gz» c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.27 R-service rshd, R-commande rsh Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.27 R-service rshd, R-commande rsh (en anglais remote shell daemon, remote shell) En général, le R-service a pour chemin : «/usr/sbin/in.rshd» ou «/usr/sbin/rshd». Syntaxe de la R-commande : rsh -l username hostname command % rsh -l besancon server.example.com date Sun Oct 12 15:20:28 MET DST 2003 c T.Besançon (v ) Administration UNIX ARS Partie / 789

215 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.27 R-service rshd, R-commande rsh Si l on ne précise pas de commande, on lance un shell en interactif. % rsh server.example.com Sun Microsystems Inc. SunOS 5.10 Generic January 2005 You have new mail. server% A chaque fois que ce sera possible, préférer une connexion en SSH (ici avec «ssh»). c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.27 R-service rshd, R-commande rsh Contrôles d accès Les contrôles d accès se font comme page 294 (chapitre sur RLOGIND) sauf pour un point : soit la connexion en RSH est explicitement autorisée par les fichiers «/etc/hosts.equiv» ou «$HOME/.rhosts» et la connexion se fait alors sans demande de mot de passe soit la connexion n est pas explicitement autorisée et elle est alors refusée et on ne demande pas de mot de passe. % rsh -l besancon server.example.com date permission denied c T.Besançon (v ) Administration UNIX ARS Partie / 789

216 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.28 R-service rcpd, R-commande rcp Chapitre 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.28 R-service rcpd, R-commande rcp (en anglais remote copy daemon, remote copy) En général, le R-service a pour chemin : «/usr/sbin/in.rcpd» ou «/usr/sbin/rcpd». Plusieurs syntaxes de la R-commande : distant vers local : rcp [-r] user@machine:filename path local vers distant : rcp [-r] path user@machine:filename c T.Besançon (v ) Administration UNIX ARS Partie / Gestionnaires de services réseau : inetd, tcpd, xinetd 7.28 R-service rcpd, R-commande rcp % rcp besancon@server.example.com:ananas.txt. % ls -l ananas -rw-r--r-- 1 besancon ars 15 Oct 12 15:18 ananas.txt % rcp ananas.txt besancon@server.example.com:/tmp/cerise.txt % rsh -l besancon server.example.com ls -l /tmp/cerise.txt -rw-r--r-- 1 besancon ars 15 Oct 12 15:22 /tmp/cerise.txt A chaque fois que ce sera possible, préférer une connexion en SSH (ici avec «scp»). c T.Besançon (v ) Administration UNIX ARS Partie / 789

217 7 Gestionnaires de services réseau : inetd, tcpd, xinetd 7.28 R-service rcpd, R-commande rcp Contrôles d accès Les contrôles d accès se font comme page 294 (chapitre sur RLOGIND) sauf pour un point : soit la connexion en RCP est explicitement autorisée par les fichiers «/etc/hosts.equiv» ou «$HOME/.rhosts» et la connexion se fait alors sans demande de mot de passe soit la connexion n est pas explicitement autorisée et elle est alors refusée et on ne demande pas de mot de passe. % rcp ananas.txt jean@server.example.com:/tmp/banane.txt permission denied c T.Besançon (v ) Administration UNIX ARS Partie / 789

218 Chapitre 8 Protocoles de transferts de fichiers FTP, TFTP c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Chapitre 8 Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd (en anglais File Transfer Protocol) Une connexion via FTP nécessite que le service FTP soit activé au niveau de inetd.conf : ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l Au niveau de «/etc/services», on voit 2 ports assignés au protocole FTP : ftp-data ftp 20/tcp 21/tcp Deux protocoles FTP en fait : FTP actif (mode par défaut sous Windows) FTP passif (mode par défaut sous Linux) c T.Besançon (v ) Administration UNIX ARS Partie / 789

219 8 Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd FTP actif CLIENT FTP FTP control connection SERVEUR FTP High port 1 port 21 FTP data connection High port 2 port 20 c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Le protocole FTP est «complexe» car c est un dialogue bidirectionnel : Un client FTP se connecte sur le port 21 («ftp» de «/etc/services») du serveur FTP et ce port 21 sert à envoyer des commandes au serveur FTP. Si les commandes nécessitent que des données soient reçues (commandes «dir», «get» par exemple) ou transmises («put» par exemple) au serveur, le client envoie une commande «PORT» au serveur indiquant un port sur lequel le serveur va créer une connexion depuis le port 20 («ftp-data» de «/etc/services»). La connexion FTP-DATA est close client dès que toutes les données sont transférées. port connexion PORT DIR data serveur port 21 port 21 port 21 port 20 c T.Besançon (v ) Administration UNIX ARS Partie / 789

220 8 Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Exemple : % ftp -v -d localhost Connected to localhost. 220 cerise FTP server (SunOS 5.8) ready. Name (localhost:besancon): besancon ---> USER besancon 331 Password required for besancon. Password: ---> PASS XXXXXXXXX 230 User besancon logged in. ftp> lcd /tmp Local directory now /tmp ftp> cd /etc ---> CWD /etc 250 CWD command successful. ftp> get motd ---> PORT 127,0,0,1,129, PORT command successful. ---> RETR motd 150 ASCII data connection for motd ( ,33085) (54 bytes). 226 ASCII Transfer complete. local: motd remote: motd 55 bytes received in seconds (62.53 Kbytes/s) ftp> quit ---> QUIT 221 Goodbye. c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd FTP passif CLIENT FTP FTP control connection SERVEUR FTP High port 1 port 21 FTP data connection High port 2 High port 3 c T.Besançon (v ) Administration UNIX ARS Partie / 789

221 8 Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Règles pour un client FTP protégé par un firewall Method Source Source Destination Destination Connection address port address port Allow outgoing control connections to server Control FTP client High FTP server 21 New channel or network FTP server 21 FTP client or network High Established Active FTP Passive FTP Allow the client to establish data channels to remote server FTP server 20 FTP client or High New network FTP client High FTP server 20 Established or network FTP client High FTP server High New or network FTP server High FTP client or High Established network c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Règles pour un serveur FTP protégé par un firewall Method Source Source Destination Destination Connection address port address port Allow incoming control connections to server Control FTP client High FTP server 21 New channel or network FTP server 21 FTP client or network High Established Active FTP Passive FTP Allow the server to establish data channels to remote client FTP server 20 FTP client or High New network FTP client High FTP server 20 Established or network FTP client High FTP server High New or network FTP server High FTP client or High Established network c T.Besançon (v ) Administration UNIX ARS Partie / 789

222 8 Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Contrôle d accès Au niveau contrôle d accès, les implémentations de base proposent : le fichier «/etc/ftpusers» contient les noms des utilisateurs non autorisés à utiliser ftp. «root» doit être exclus comme d habitude. le fichier «/etc/shells» contient les shells des utilisateurs autorisés à utiliser ftp. Moralité : pour interdire un utilisateur à utiliser FTP : indiquer le login de la personne au niveau de «/etc/ftpusers» faire en sorte que le shell de la personne ne soit pas dans «/etc/shells» Pour configurer un FTP anonyme, se reporter aux deux FAQ : «ftp://ftp.lip6.fr/pub/doc/faqs/ftp-list/faq.gz» «ftp://ftp.lip6.fr/pub/doc/faqs/computer-security/anonymous-ftp-faq.gz» c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.1 Protocole FTP, ftp, ftpd Implémentations de serveurs FTP Outre les versions fournies par les constructeurs, il y a plusieurs démons du domaine public plus performants : « « « c T.Besançon (v ) Administration UNIX ARS Partie / 789

223 8 Protocoles de transferts de fichiers FTP, TFTP 8.2 Protocole TFTP, tftp, tftpd Chapitre 8 Protocoles de transferts de fichiers FTP, TFTP 8.2 Protocole TFTP, tftp, tftpd TFTP : Trivial File Transfer Protocol Une connexion via tftp nécessite que le service tftp soit activé au niveau de inetd.conf : tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot TFTP, c est en gros FTP sans pouvoir lister les directories distants et ne nécessitant pas de mot de passe pour récupérer ou déposer des fichiers! En fait, celui qui utilise TFTP sait ce qu il veut récupérer et n a pas besoin de lister le directory. Par exemple, récupération d un fichier de configuration pour : terminal X imprimante HP réseau c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.2 Protocole TFTP, tftp, tftpd On récupére les fichiers dans la sous arborescence /tftpboot. Le danger : un démon tftpd mal configuré permet de récupérer tout fichier hors de «/tftpboot». Le fichier «/etc/passwd» par exemple. vérifier les options de lancement. Traditionnellement utiliser l option «-s» au niveau de «/etc/inetd.conf» : tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot c T.Besançon (v ) Administration UNIX ARS Partie / 789

224 8 Protocoles de transferts de fichiers FTP, TFTP 8.2 Protocole TFTP, tftp, tftpd A noter : il est parfois utile de faire le lien symbolique suivant : # cd /tftpboot # ln -s. tftpboot car des requêtes portent parfois sur des noms du type «/tftpboot/fichier». % cd /tftpboot % ls -l drwxr-xr-x 2 root wheel 1536 Jan 4 15:02 cisco/ drwxr-sr-x 7 root wheel 512 Nov hds/ drwxr-sr-x 2 root wheel 512 Sep hp/ drwxr-sr-x 4 root wheel 512 Dec ncd/ drwxr-sr-x 2 root wheel 512 Mar plaintree/ drwxr-xr-x 2 root wheel 512 Aug sun/ lrwxrwxrwx 1 root wheel 1 May tftpboot ->. drwxr-sr-x 3 root wheel 512 Feb usr/ c T.Besançon (v ) Administration UNIX ARS Partie / Protocoles de transferts de fichiers FTP, TFTP 8.2 Protocole TFTP, tftp, tftpd Utilisation de TFTP sur CISCO pour télécharger des configurations ou des firmware. Idem sur d autres matériels réseau : par exemple marque FOUNDRY mise en place de la configuration du FOUNDRY via TFTP sur un serveur UNIX : copy tftp start router/4802.cfg reload sauvegarde de la configuration du FOUNDRY sur UNIX via TFTP : touch /tftpboot/router/downloads/x.y chown nobody:nobody /tftpboot/router/downloads/x.y copy run tftp router/downloads/x.y c T.Besançon (v ) Administration UNIX ARS Partie / 789

225 Chapitre 9 Remote Procedure Call (RPC) c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.1 Introduction Chapitre 9 Remote Procedure Call (RPC) 9.1 Introduction Les Remote Procedure Calls (RPC) sont nés dans les années : diminution des coûts des matériels augmentation des puissances de calcul augmentation des capacités de stockage Bref, passage à une informatique de systèmes répartis et de systèmes distribués (utiliser le matériel le plus performant pour une tâche donnée, accroître la disponibilité des systèmes). c T.Besançon (v ) Administration UNIX ARS Partie / 789

226 9 Remote Procedure Call (RPC) 9.1 Introduction Principe d un programme classique : % prog.exe int main(int argc, char *argv[]) { int n; n = coucou(); int coucou() { return(33); } exit(0); } c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.1 Introduction Principe d un programme réparti utilisant une Remote Procedure Call (RPC) : % prog.exe int main(int argc, char *argv[]) { int n; n = coucou(); int coucou() { return(33); } exit(0); } RESEAU c T.Besançon (v ) Administration UNIX ARS Partie / 789

227 9 Remote Procedure Call (RPC) 9.2 Protocole External Data Representation (XDR) Chapitre 9 Remote Procedure Call (RPC) 9.2 Protocole External Data Representation (XDR) Rappel sur les processeurs : processeurs big endian 0x = processeurs little endian 0x = 0x01 0x02 0x03 0x04 0x04 0x03 0x02 0xNNNN + 0xNNNN 0xNNNN + 0xNNNN + 0xNNNN 0xNNNN + 3 c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.2 Protocole External Data Representation (XDR) Nécessité de choisir un encodage lors des échanges RPC! Encodage big-endian retenu Cf fonctions C «ntohs()» (network to host short), «ntohl()» (network to host long), «htons()» (host to network short), «htonl()» (host to network long). Encodage des données plus générales (structures, tableaux, etc.) = XDR Les RPC utilisent massivement XDR. c T.Besançon (v ) Administration UNIX ARS Partie / 789

228 9 Remote Procedure Call (RPC) 9.3 Modèle Client / Serveur RPC Chapitre 9 Remote Procedure Call (RPC) 9.3 Modèle Client / Serveur RPC Les Remote Procedure Calls (RPC) utilisent un modèle client / serveur : Le client est le processus qui appelle une procédure distante. Le serveur est le processus qui réalise la Remote Procedure. La communication se fait via TCP. processus local processus distant CLIENT PROCEDURE API RPC STUB client STUB serveur RPC runtime RPC runtime c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.4 Localisation des procédures RPC : portmapper, rpcbind Chapitre 9 Remote Procedure Call (RPC) 9.4 Localisation des procédures RPC : portmapper, rpcbind L appel à la procédure distante nécessite de localiser la procédure distante (numéro de port TCP) sur la machine distante. Le processus «portmapper» (autre nom possible : «rpcbind») joue le rôle de serveurs de noms RPC. Il écoute sur le port TCP 111. Principe : une procédure distante s enregistre auprès du portmapper on demande au portmapper où se trouve la procédure on appelle ensuite la procédure Le processus «portmapper» (autre nom possible : «rpcbind») doit être démarré avant de lancer des processus enregistrant des RPC (voir scripts de démarrage). c T.Besançon (v ) Administration UNIX ARS Partie / 789

229 9 Remote Procedure Call (RPC) 9.4 Localisation des procédures RPC : portmapper, rpcbind 1 Ou se trouve ananas() v2? processus portmapper port ananas() v2 == port ananas(), v2 = port 3248 banane(), v2 = port 2147 banane(), v3 = port 2148 etc. processus 927 processus procedure ananas() port 3248 port 2147 port 2148 procedure banane() version 2 version 2, version 3 c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.5 Liste des procédures RPC : rpcinfo Chapitre 9 Remote Procedure Call (RPC) 9.5 Liste des procédures RPC : rpcinfo (en anglais RPC information) Syntaxe : «rpcinfo [-p] [-s] hostname» Par exemple : % rpcinfo -s rpcinfo -s program version(s) netid(s) service owner ,3,4 udp,tcp,ticlts,ticotsord,ticots rpcbind super ,3,2,1 tcp,udp nlockmgr ticots,ticotsord,ticlts,tcp,udp status super ,3,2 udp,ticlts rstatd super ,2 udp,ticlts,tcp,ticotsord,ticots rusersd super udp,ticlts rquotad super ,2,1 ticots,ticotsord,tcp,ticlts,udp mountd super ,3,2 tcp,udp nfs ,2 tcp,udp nfs_acl 1... c T.Besançon (v ) Administration UNIX ARS Partie / 789

230 9 Remote Procedure Call (RPC) 9.5 Liste des procédures RPC : rpcinfo % rpcinfo -p program vers proto port service tcp 111 rpcbind tcp 111 rpcbind tcp 111 rpcbind udp 111 rpcbind udp 111 rpcbind udp 111 rpcbind udp 4045 nlockmgr udp 4045 nlockmgr udp 4045 nlockmgr udp 4045 nlockmgr tcp 4045 nlockmgr tcp 4045 nlockmgr tcp 4045 nlockmgr tcp 4045 nlockmgr... c T.Besançon (v ) Administration UNIX ARS Partie / Remote Procedure Call (RPC) 9.6 Contrôle d accès Chapitre 9 Remote Procedure Call (RPC) 9.6 Contrôle d accès Avec LINUX est apparu un contrôle d accès au niveau de PORTMAP via sa compilation avec la librairie des TCPWRAPPERS. Les contrôles d accès se font donc comme page 272 via «/etc/hosts.allow». c T.Besançon (v ) Administration UNIX ARS Partie / 789

231 Chapitre 10 Partage de fichiers NFS c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.1 Introduction Chapitre 10 Partage de fichiers NFS 10.1 Introduction NFS Network File System c est l accès de façon transparente pour l utilisateur à des fichiers résidants sur des machines distantes. Actuellement, NFS version 2 la plus répandue. NFS version 3 existe et est disponible mais il existe des incompatibilités d implémentations entre constructeurs. NFS version 4 est en étude. Cf « ou « c T.Besançon (v ) Administration UNIX ARS Partie / 789

232 10 Partage de fichiers NFS 10.2 Principes de NFS Chapitre 10 Partage de fichiers NFS 10.2 Principes de NFS Client Serveur System calls System calls VNODE / VFS VNODE / VFS Client routines NFS File system Server routines NFS File system RPC / XDR RPC / XDR RPC / XDR RPC / XDR Reseau c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.2 Principes de NFS On a deux aspects dans NFS : client NFS et serveur NFS. CLIENT NFS SERVEUR NFS # mount % prog rpc.statd rpc.lockd portmap (rpcbind) portmap (rpcbind) rpc.mountd nfsd rpc.statd rpc.lockd RESEAU c T.Besançon (v ) Administration UNIX ARS Partie / 789

233 10 Partage de fichiers NFS 10.2 Principes de NFS Le client NFS fait tourner les démons «biod» (ou «nfsiod»), «rpc.lockd» et «rpc.statd». CLIENT NFS # mount % prog rpc.statd rpc.lockd portmap (rpcbind) RESEAU c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.2 Principes de NFS Le serveur NFS fait tourner les démons «portmap» (ou «rpcbind»), «mountd» (ou «rpc.mountd»), «nfsd», «rpc.statd» et «rpc.lockd». SERVEUR NFS portmap (rpcbind) rpc.mountd nfsd rpc.statd rpc.lockd RESEAU c T.Besançon (v ) Administration UNIX ARS Partie / 789

234 10 Partage de fichiers NFS 10.2 Principes de NFS Montage NFS : filehandle SERVEUR NFS autorisations d exportation : /etc/exports RESEAU rpc.mountd 0 3 calcul du filehandle /home # mount server:/home /mnt /mnt + filehandle (= fh0) / CLIENT NFS kernel c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.2 Principes de NFS Ouverture d un fichier NFS : utilisations des filehandles SERVEUR NFS Serveur NFS / port 2049 lookup(jardin, fh0) fh1 lookup(cerise.txt, fh1) fh2 kernel RESEAU % prog.exe open(/mnt/jardin/cerise.txt) kernel CLIENT NFS c T.Besançon (v ) Administration UNIX ARS Partie / 789

235 10 Partage de fichiers NFS 10.2 Principes de NFS Lecture/Ecriture d un fichier NFS : utilisations des filehandles SERVEUR NFS Serveur NFS / port 2049 read(fh2, 0, 1024) read(fh2,..., 1024) kernel RESEAU % prog.exe 2... read() / write() CLIENT NFS 1 kernel c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.2 Principes de NFS Verrouillage NFS (1) : fonctionnement normal SERVEUR NFS /etc/sm 3 3 rpc.lockd 3 rpc.statd 2 RESEAU rpc.lockd rpc.statd CLIENT NFS 1 fcntl() lockf() % prog.exe c T.Besançon (v ) Administration UNIX ARS Partie / 789

236 10 Partage de fichiers NFS 10.2 Principes de NFS Verrouillage NFS (2) : reboot du client NFS SERVEUR NFS /etc/sm 3 2 rpc.lockd 2 rpc.statd 1 RESEAU rpc.lockd rpc.statd CLIENT NFS reboot du client NFS termine c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.2 Principes de NFS Verrouillage NFS (3) : reboot du serveur NFS SERVEUR NFS reboot du serveur NFS termine /etc/sm 1 4? rpc.lockd rpc.statd 2 RESEAU nouvelle demande des verrous NFS? CLIENT NFS 4? rpc.lockd % prog.exe 3 rpc.statd perte des verrous NFS c T.Besançon (v ) Administration UNIX ARS Partie / 789

237 10 Partage de fichiers NFS 10.2 Principes de NFS Suppression de fichier NFS ouvert exemple.txt.nfsxxxxxxxxxx rm read write c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.3 Lancement de NFS Chapitre 10 Partage de fichiers NFS 10.3 Lancement de NFS DIGITAL UNIX On règle l aspect NFS par la commande «nfssetup» qui modifie alors le fichier «/etc/rc.config» :... NFS_CONFIGURED="1" export NFS_CONFIGURED NFSSERVING="1" export NFSSERVING NONROOTMOUNTS="1" export NONROOTMOUNTS NUM_TCPD="8" export NUM_TCPD NUM_UDPD="8" export NUM_UDPD NUM_NFSIOD="7" export NUM_NFSIOD NFSLOCKING="1" export NFSLOCKING... c T.Besançon (v ) Administration UNIX ARS Partie / 789

238 10 Partage de fichiers NFS 10.3 Lancement de NFS Linux Au niveau de «/etc/sysconfig/network», on indique via la variable «NETWORKING» si l on veut les services réseau (dont NFS). Le script de démarrage «/etc/rc.d/rc3.d/s15nfsfs» suivant la valeur de NETWORKING lance ou pas un client NFS. Le script de démarrage «/etc/rc.d/rc3.d/s60nfs» suivant la valeur de NETWORKING et suivant l existence de «/etc/exports» lance ou pas un serveur NFS. Solaris La lecture de «/etc/init.d/nfs.client» renseigne sur la façon de démarrer un client NFS. La lecture de «/etc/init.d/nfs.server» apprend que la machine démarre un serveur NFS s il existe le fichier d exportation «/etc/dfs/dfstab». c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.4 Exportation NFS, /etc/exports, /etc/dfs/dfstab Chapitre 10 Partage de fichiers NFS 10.4 Exportation NFS, /etc/exports, /etc/dfs/dfstab Le partage de disques repose sur l exportation par une machine d arborescences. L exportation peut être en read-only ou en read-write. L exportation se fait au niveau du fichier /etc/exports en général. Suivant l UNIX, la syntaxe n est pas la même : DIGITAL UNIX : fichier «/etc/exports» : /var/spool/mail -access=client-nfs.example.com Linux : fichier «/etc/exports» : /home client-nfs.example.com(rw) /zip client-nfs.example.com(rw) Solaris : fichier «/etc/dfs/dfstab» : # pathname resource fstype specific_options description /export/home - nfs rw=.example.com c T.Besançon (v ) Administration UNIX ARS Partie / 789

239 10 Partage de fichiers NFS 10.4 Exportation NFS, /etc/exports, /etc/dfs/dfstab Comment faire prendre connaissance de modifications dans le fichier «/etc/exports» (ou équivalent)? Méthode 1 : on ne fait rien ; le fichier «/etc/exports» est consulté lors de toute demande de montage de disque. Par exemple DIGITAL UNIX. Méthode 2 : on envoie un signal au programme «mountd» gérant les montages : # kill -HUP cat /var/run/mountd.pid Par exemple Linux, FreeBSD. Méthode 3 : une commande spécialisée existe : share, shareall (unshare, unshareall) sur Solaris # unshareall # showmount -e no exported file systems for serveur-nfs.example.com # shareall # showmount -e export list for serveur-nfs.example.com: /infosystems client-nfs.example.com c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.5 Exportation root NFS Chapitre 10 Partage de fichiers NFS 10.5 Exportation root NFS Le problème principal est celui de l équivalence root par NFS : quels droits possède le root d une machine cliente NFS sur les fichiers exportés par un serveur NFS? Un fichier de droits «rw » sur le serveur NFS (où le root peut le lire) peut-il être lu par root sur un client NFS? La réponse est fonction du contexte mais cela se paramètre au niveau de «/etc/exports». Une requête émanant de root sera sauf précision contraire convertie au nom de l utilisateur «nobody» : % grep nobody /etc/passwd nobody:*:65534:65534:unprivileged user:/nonexistent:/sbin/nologin (attention : parfois c est l utilisateur «nfsnobody» mais le principe reste le même) c T.Besançon (v ) Administration UNIX ARS Partie / 789

240 10 Partage de fichiers NFS 10.5 Exportation root NFS Exemple de la conversion de l UID lors de la requête (la partition montée est exportée sans droit root NFS) : # mount -t nfs serveur-nfs.example.com:/adm/backup/arch /mnt # id uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem) # cd /mnt # df. Filesystem 1024-blocks Used Available Capacity Mounted on serveur-nfs.example.com:/adm/backup/arch % /mnt # touch test.txt # ls -l total 0 -rw root daemon 75 Feb 3 15:01 motd -rw-r--r-- 1 nobody nogroup 0 Feb 3 14:59 test.txt # cat motd cat: motd: Permission denied c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.5 Exportation root NFS Exportation avec root NFS Mêmes fichiers que précédemment : exemple sur DIGITAL UNIX : /var/spool/mail -root=client.example.com,access=client.example.com exemple sur Linux : /var/spool/mail client.example.com(rw,no_root_squash) exemple sur Solaris : /export/home - nfs rw=.example.com,root=client.example.com c T.Besançon (v ) Administration UNIX ARS Partie / 789

241 10 Partage de fichiers NFS 10.5 Exportation root NFS Exportation sans root NFS Mêmes fichiers que précédemment : exemple sur DIGITAL UNIX : /var/spool/mail -access=client.example.com exemple sur Linux : /var/spool/mail client.example.com(rw,root_squash) exemple sur Solaris :... /opt - nfs rw=client.example.com /usr/local - nfs rw=.example.com /var/mail - nfs rw=.example.com c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.6 Règle de non transitivité NFS Chapitre 10 Partage de fichiers NFS 10.6 Règle de non transitivité NFS Il n y a pas de transitivité NFS. Si A exporte «/partition» à B Si B monte «/partition» en «/partition2» et exporte «/partition2» à C alors C n a pas accès au contenu du «/partition» initial! Sinon il n y aurait aucune sécurité, aucun contrôle possible d exportation. c T.Besançon (v ) Administration UNIX ARS Partie / 789

242 10 Partage de fichiers NFS 10.7 Montage NFS manuel Chapitre 10 Partage de fichiers NFS 10.7 Montage NFS manuel Syntaxe usuelle : mount -t nfs serveur:/arborescence /point/montage # mount -t nfs serveur-nfs.example.com:/export/home /mnt # df /mnt Filesystem 1k-blocks Used Available Use% Mounted on serveur-nfs.example.com:/export/home % /mnt # umount /mnt c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS 10.8 Montage NFS automatique Chapitre 10 Partage de fichiers NFS 10.8 Montage NFS automatique Les montages automatiques se règlent au niveau de /etc/fstab (ou équivalent) :... serveur-nfs.example.com:/export/home /mnt nfs hard,intr La syntaxe est celle montrée ci dessus sur tous les systèmes UNIX utilisant un fichier «/etc/fstab». Une fois le fichier «/etc/fstab» configuré, on peut faire les choses suivantes : 1 Monter une partition distante bien précise : # mount /users 2 Monter toutes les partitions distantes : # mount -t nfs -v -a c T.Besançon (v ) Administration UNIX ARS Partie / 789

243 10 Partage de fichiers NFS 10.9 Option de montage NFS soft Chapitre 10 Partage de fichiers NFS 10.9 Option de montage NFS soft Option de montage «soft» : si pour une raison ou pour une autre, les opérations RPC implantant la requête NFS viennent à échouer, cette requête NFS échoue elle aussi. On peut apparenter cette situation à celle d un disque local tombant en panne. Une manifestation de ce problème est qu il peut apparaître des blocs remplis de caractères NULL dans des fichiers nouvellement écrits à travers NFS sur une partition qui aura montré des problèmes. c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS Option de montage NFS hard Chapitre 10 Partage de fichiers NFS Option de montage NFS hard Option de montage «hard» : si pour une raison ou pour une autre, les opérations RPC implantant la requête NFS viennent à échouer, cette requête NFS est soumise à nouveau et cela jusqu à ce qu elle aboutisse. On peut apparenter cette situation à celle d un disque local très lent. Pour éviter que dans le cas hard, la requête NFS ne soit transmise ad vitam eternam, on peut faire le montage en mode hard,intr ce qui autorise son interruption au clavier ou via des envois de signaux. En pratique, on utilisera toujours les montages hard,intr pour les montages des partitions auxquelles on accède en lecture/écriture. c T.Besançon (v ) Administration UNIX ARS Partie / 789

244 10 Partage de fichiers NFS Vérification des exportations : showmount Chapitre 10 Partage de fichiers NFS Vérification des exportations : showmount En cas de problème dans le montage NFS d une partition on peut vérifier d abord si l exportation indispensable est déjà assurée. La commande à utiliser est «showmount -e» : % showmount -e serveur-nfs.example.com Export list for serveur-nfs.example.com: /export/home.example.com /opt client-nfs.example.com /usr/local.example.com /var/mail.example.com c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS Vérification des exportations : rpcinfo Chapitre 10 Partage de fichiers NFS Vérification des exportations : rpcinfo On peut aussi vérifier à distance si le serveur NFS fait tourner le démon mountd via la commande «rpcinfo». % rpcinfo -p serveur-nfs.example.com grep mount udp mountd udp mountd udp mountd tcp mountd tcp mountd tcp mountd c T.Besançon (v ) Administration UNIX ARS Partie / 789

245 10 Partage de fichiers NFS Messages d erreur NFS Chapitre 10 Partage de fichiers NFS Messages d erreur NFS Un message d erreur classique prend la forme : NFS write error: on host serveur-nfs.example.com remote file system full Parfois c est hermétique comme message : NFS write error 60 on host nfs-client.example.com fh a0000 cdbe 66b10eac a0000 1d00 5fdbece5 Pour le décoder, se reporter à «<sys/errno.h>». Ici on déduit : #define ETIMEDOUT 60 /* Connection timed out */ c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS Automounter Chapitre 10 Partage de fichiers NFS Automounter Les montages rencontrés jusqu à présent sont permanents. Un automounter rend les montages temporaires : un montage ne dure guère que le temps nécessaire ; quand il est nécessaire, on monte la partition distante que l on démonte quand on n en a plus besoin. Il existe 3 automounters : «automount» fourni par les constructeurs (et d origine SUN) «amd» ; version logiciel libre dont le développement stagne ftp://ftp.cs.columbia.edu/pub/amd «am-utils», bâti sur la base de «amd» « c T.Besançon (v ) Administration UNIX ARS Partie / 789

246 10 Partage de fichiers NFS Machines diskless Chapitre 10 Partage de fichiers NFS Machines diskless Une machine diskless est une machine UNIX sans disque dur local. Principe : 1 La machine UNIX est mise sous tension. 2 La machine UNIX envoie sur le réseau son adresse ethernet (MAC address). Par exemple via PXE sur des cartes réseau récentes. 3 La machine récupére son adresse IP et on lui indique où télécharger un noyau et comment. Par exemple renseignements renvoyés par DHCP. 4 La machine télécharge le noyau. Par exemple par TFTP. 5 Le noyau monte par NFS la partition de «/». 6 Le programme «init» prend la main et réalise les opérations de montage des partitions indiquées dans «/etc/fstab». Ici les partitions seront donc montées par NFS. c T.Besançon (v ) Administration UNIX ARS Partie / Partage de fichiers NFS Annexe 1 Chapitre 10 Partage de fichiers NFS Annexe 1 Ci joint dans la version imprimée de ce cours, un document sur le procédé KICKSTART. c T.Besançon (v ) Administration UNIX ARS Partie / 789

247 Kickstart Fedora Kickstart Red Hat Magazine 2004 N 3 Utilisez Fedora Kickstart en réseau pour effectuer une nouvelle installation en peu de temps. L inux est de plus en plus utilisé, non seulement au sein de très grands réseaux, mais également dans certaines situations où il est nécessaire d installer de nombreux ordinateurs ou bien de procéder à une nouvelle installation en un laps de temps réduit. Par exemple, dans le cas de clusters d ordinateurs ou d une réinstallation manuelle de stations de travail dans les réseaux d entreprises, suite au dysfonctionnement d un disque dur... Opérations qui demandent beaucoup trop de temps et d énergie au personnel. Toutefois, en cas d installations exécutées normalement de façon automatique, dans le but de réinstaller sur le disque dur d un serveur ou d un poste de travail des données très importantes, utilisez Kickstart avec prudence parce qu une simple erreur dans le fichier de configuration pourrait provoquer la perte de ces données. De ce fait, soyez très vigilant lors de la création du fichier de configuration Kickstart. Types d installations Kickstart, disponible dans l Installer de Fedora, est la solution idéale à ces problèmes, puisqu il permet d effectuer automatiquement une installation complète, y compris l exécution de scripts adaptés pour une configuration ou des besoins spécifiques. Pourquoi Kickstart? Par rapport aux autres méthodes d installation, Kickstart offre de nombreux avantages. Il est possible de configurer de façon centralisée des installations types pour des groupes d ordinateurs, étant donné que les divers composants hardware reconnus par le programme d installation de Red Hat peuvent être ignorés dans le fichier de configuration. La méthode Kickstart ne requiert, comme modèle d installation, qu un seul fichier de description qui utilise une syntaxe spécifique pour indiquer à l Installer les opérations qu il doit exécuter. Ce fichier de description introduit le second grand avantage de la méthode Kickstart : aucune image d installation propre à chaque PC n est nécessaire, comme dans le cas de presque tous les autres programmes d installation ou de rétablissement d installation. Kickstart, en effet, n utilise que les supports d installation de Fedora. En outre, le fichier de description est substantiellement indépendant de la version. Il est, par conséquent, possible d utiliser le même fichier, avec cependant quelques limites, comme par exemple, le choix des paquetages, pour les installations courantes et futures de Fedora. En pratique, Kickstart installe à chaque fois un système avec les mêmes caractéristiques mais utilise comme base la distribution correspondante et le programme d installation relatif. Pour le stockage des fichiers de description d installation, Kickstart offre deux méthodes différentes. La méthode basée sur des disques nécessite un disque de lancement approprié pour chaque ordinateur installé. Cette méthode prévoit l utilisation, soit du disque de lancement d installation (créé sur la base des fichiers des images boot. img) de la distribution Linux utilisée, soit du fichier de description. la méthode basée sur le réseau prévoit le chargement du fichier Kickstart à partir d un serveur approprié. Comme support de lancement, il est possible d utiliser un disque ou, par exemple, un PXE ou encore un environnement créé pour le lancement à partir de cartes réseau déterminées. La première méthode est conseillée pour de petites installations, tandis que pour des installations de plus grande ampleur, il est souhaitable d utiliser la seconde méthode : celle basée sur réseau. Dans ce cas, il n est pas nécessaire de consacrer trop de temps à la personnalisation du serveur pour Kickstart. Pour démarrer une installation automatique, il faut de toute façon copier les supports d installation de Red Hat sur le serveur, et ce, indépendamment du type d installation désirée : basée sur disque ou sur réseau. Dans cet article, l installation basée sur CD-ROMs ne sera pas abordée, puisqu elle ne permet pas l installation automatique sans une intervention minimale de l utilisateur. 65

248 Fedora Kickstart Red Hat Magazine 2004 N 3 Un répertoire du disque (ext2) Un partage NFS Un partage http (Webserver) Un partage FTP Les CD-ROMs d installation de Red Hat (qui n autorisent pas l installation automatique). Tableau 1 : Supports de base d installation. Copie des supports d installation sur le serveur Pour copier les supports d installation sur le serveur, il est avant tout nécessaire que la partition correspondante dispose d espace suffisant : environ 2 Go. Il faut ensuite créer un nouveau répertoire dans lequel sauvegarder les supports d installation. Dans l exemple suivant est utilisé le répertoire : /kickstart/fc1a. Insérez le premier CD de Fedora dans le lecteur CD-ROM approprié, et tapez ensuite : #mount /mnt/cdrom #cp af /mnt/cdrom/redhat /kickstart/fc1a #cp /mnt/cdrom/release-notes* /kickstart/fc1a (n exécutez cette dernière commande que pour le premier CD-ROM) #umount /mnt/cd-rom Répétez l opération pour les 2ème et 3ème CDs d installation. De cette façon, les paquetages d installation et tous les programmes binaires de Fedora sont copiés dans le répertoire kickstart/fc1a. Partages du serveur Exportez la base d installation afin de permettre aux clients de la repérer sur le serveur. Pour exécuter l exportation, de nombreuses méthodes sont disponibles, toutefois les partages NFS ou HTTP sont les plus communément utilisés. Dans l exemple suivant, le partage NFS sera utilisé car, dans le cas d une installation basée sur réseau, Kickstart requiert le fichier de configuration correspondant sur partage NFS. En principe, il est également possible d exécuter des installations par le biais d autres supports de base. Par exemple, un ordinateur qui fournit des données partagées sur le Web pourrait être utilisé comme support de base pour d importantes installations. Pour créer le partage NFS, il faut vérifier que les paquetages RPM nécessaires sont disponibles sur le serveur. Pour cela, tapez la commande rpm ci-dessous : #rpm q portmap nfs-utils La commande doit renvoyer les noms des deux programmes. Contrôlez que le répertoire complet /kickstart est bien exporté (voir le Listing 1). /kickstart Listing 1 : /etc/exports *(ro,all_squash) Par la suite, il sera possible de sauvegarder les fichiers de configuration de Kickstart dans ce répertoire. Activez le service NFS en tapant : #/etc/init.d/nfs start Si un message d erreur comme celui-ci apparaît : Starting NFS quotas: Cannot register service: RPC: Unable to receive... il faudra aussi lancer le mapper des ports via la commande : #/etc/init.d/portmap start Configuration DHCP Pour effectuer une installation à partir d un serveur disposant des fichiers de configuration, il faut qu un serveur DHCP soit disponible sur le réseau de l ordinateur à installer. Dans l Encadré 2 est représenté un fichier de configuration un peu plus complexe pour le daemon DHCP, qui se base sur 2 sous-réseaux reliés de façon logique au calculateur. Tous les sous-réseaux dont est responsable le daemon DHCP d un ordinateur doivent toujours être directement reliés, par exemple au moyen d une carte réseau, avec l ordinateur correspondant. Assurez-vous, en outre, qu un seul serveur DHCP est utilisé par sous-réseau, car l utilisation de plusieurs serveurs pourraient distribuer les données de configuration de façon arbitraire. Pour installer et activer le daemon DHCP, éventuellement non installé, tapez les commandes suivantes : #up2date dhcp #vim /etc/dhcpd.conf (élaboration du fichier de configuration) #/etc/init.d/dhcp start Si le serveur DHCP est actif, l installation Kickstart recevra l adresse IP du serveur DHCP et choisira ensuite le fichier de configuration Kickstart en service. L option next-server spécifie le serveur NFS qui contient le fichier, tandis que l option filename assigne au programme d installation le nom du partage NFS. Kickstart cherchera ensuite dans ce répertoire le fichier de configuration selon le schéma suivant : < Adresse IP >-kickstart Naturellement, il est également possible de créer dans ce répertoire des liens symboliques ainsi que des groupes. Il est, par exemple, possible de créer un fichier Kickstart pour un groupe de stations de travail et l utiliser seulement pour les adresses IP intéressées. L exemple suivant illustre la création de ce type de fichier Kickstart. 66

249 Fedora Kickstart Red Hat Magazine 2004 N 3 # Définitions globales: option domain-name reseau-essai.redhat.de ; default-lease-time 3600; max-lease-time 7200; ddns-update-style none; # Definition du premier sous-réseau (tous les # paramètres spécifiés dans le sous-réseau, # ne sont valables que pour tel réseau). subnet netmask { option routers ; # Passerelle prédéfinie option domain-name-servers ; # Server DNS option subnet-mask ; # Données du masque de sous-réseau next-server ; # Adresse du serveur NFS avec le fichier # de configuration Kickstart filename /kickstart/ ; # Répertoire qui contient le fichier # Kickstart (Schéma: $[Adresse IP client]). range ; # Adresse assignée par le serveur # (dans ce cas de à ) # Pour une installation et une # diversification efficaces, les clients à # installer doivent toujours # avoir la même adresse IP, ceci parce # que le fichier Kickstart est sélectionné # en fonction de l adresse IP. Création d un fichier de configuration avec redhatconfig-kickstart La version courante de Fedora comprend l outil redhat-config-kickstart. Si cet outil n est pas encore installé sur le système, utilisez up2date pour exécuter une telle opération. Pour le lancer, tapez redhat-configkickstart. Apparaîtra alors une fenêtre de lancement (Figure 1) qui offre les mêmes options qu une installation Fedora. L outil permet, soit de modifier un fichier de configuration existant, à condition qu il ait été créé avec Red Hat Tool, soit d en créer un nouveau. Explorez les éléments du menu, visibles à gauche. Encore une fois, faites très attention si des données importantes ont été installées sur l ordinateur. L élément du menu Configuration de base comprend des options très importantes comme, par exemple, celle relative à la Composition vocale ou à l établissement du mot de passe principal. L option Méthode d installation permet de choisir diverses bases d installation et, en outre, d effectuer une nouvelle installation ou bien mettre à jour une installation déjà existante de Fedora. Les options du bootloader comprennent les bases pour la configuration de Grub/Lilo. Toutefois à cet endroit, il n est pas possible d exécuter une configuration détaillée comme, par exemple, celle d un système dual-boot. La section Information sur la partition permet de spécifier le partitionnement. A cet effet, deux options spécifiques de Kickstart sont disponibles : ondisk qui permet de créer une partition déterminée sur un disque dur spécifique et onpart qui permet, par contre, d utiliser une partition déjà existante. group { use-host-decl-names on; host workstation1 { # Nom de l ordinateur hardware ethernet 00:cb:0b:18:10:45; # Adresse MAC de la carte réseau fixed-address ; # Adresse IP à assigner à l ordinateur } #? Ici il est possible de spécifier #? d autres ordinateurs. } # Fin de l adresseip de l ordinateur spécifié } # Fin du sous-réseau # Il est possible de spécifier d autres # sous-réseaux en suivant le même schéma subnet netmask { #? Définitions? } Encadré 2 : /etc/dhcpd.conf Figure 1 : Configuration de base. 67

250 Fedora Kickstart Red Hat Magazine 2004 N 3 Puisque Kickstart utilise le programme d installation de Red Hat et, par conséquent, son système de détection hardware, il n est pas nécessaire de spécifier les paramètres hardware dans les éléments de menus cités ciaprès. Pendant l installation, les drivers appropriés seront configurés automatiquement. En général, les données d authentification ne doivent être modifiées que lorsqu on utilise un système d authentification de réseau de type NIS ou LDAP. Si, par contre, le système appartient à un réseau local protégé, il est possible de désactiver l option Configuration Firewall. En ce qui concerne la Configuration de X, avant d activer le lancement automatique du système X Window, vérifiez si vous avez sélectionné la configuration appropriée. Bien qu aujourd hui il soit possible de résoudre presque tous les problèmes hardware, l auteur comme le distributeur devraient faire très attention avant de satisfaire des demandes hardware particulières. La configuration XFree, après que l installation ait été effectuée avec l outil redhatconfig-xfree86, représente le meilleur compromis. L outil graphique permet de sélectionner les paquetages mais seulement des groupes de paquetages, comme illustré à la Figure 2. Si l on désire spécifier un réglage particulier, par exemple sélectionner un unique paquetage, il faudra modifier manuellement le fichier de configuration. Cet argument est traité plus en détail dans un autre paragraphe du présent article. la configuration de Kickstart en cliquant sur Fichier-> Enregistrer fichier. Le fichier, obtenu pour le réseau utilisé ici comme exemple est semblable à celui illustré dans l Encadré 3. Un fichier de ce type sera présenté plus en détail dans le paragraphe suivant. # Généré par le configurateur Kickstart lang en_us # Langue du système langsupport de_de --default=en_us # Langues à installer keyboard de-latin1-nodeadkeys # Type de clavier mouse generic3ps/2 # Type de souris timezone Europe/Berlin # Fuseau horaire rootpw --iscrypted $1$To1ZVQMJ$SjOFyd7tZ2y. fr.g2omt// # Password principal reboot # Redémarrage après l installation text # Installation en mode texte install # Exécute une réinstallation et non # pas une mise à jour nfs --server= dir=/kickstart/ FC1A # Support d installation bootloader --location=mbr # Endroit où installer le chargeur de démarrage zerombr yes # Efface le MBR principal clearpart --all --initlabel # Elimine toutes # les partitions existantes et la table des # partitions # Informations sur le partionnement part /boot --fstype ext3 --size asprimary part / --fstype ext3 --size 1 --grow part swap --size 512 # Options d authentification Figure 2 : Sélection des paquetages. La même configuration sera utilisée pour les scripts %pre et %post. Les scripts permettent d apporter des modifications définies par l utilisateur. Il est possible, par exemple, de contrôler les données en réseau, comme envoyer un message avec le texte : «Administrateur, l ordinateur a été installé» et plus encore, sans poser de limites à la créativité. Après avoir réglé toutes les options désirées, enregistrez auth --useshadow --enablemd5 # Configuration de l interface réseau network --bootproto=static -- ip= netmask= gateway= nameserver= device=eth0 68

251 Fedora Kickstart Red Hat Magazine 2004 N 3 firewall --disabled # Désactive les règles du # firewall # Configuration de Xfree86 xconfig --depth=32 --resolution=1280x defaultdesktop=kde # Selection des paquets (résoud automa- # tiquement les dépendances) %packages X Window KDE Desktop Graphical Administration Printing Support Encadré 3 : ks.cfg Création manuelle d un fichier de configuration Pourquoi créer manuellement un fichier de configuration, opération plutôt compliquée, alors que tout ou presque est disponible dans l outil Fedora? Les réponses à cette question sont multiples. Soit parce que le programme d installation ne reconnaît pas un composant hardware, telle une carte réseau, soit parce que l utilisateur désire personnaliser le système avec des scripts. Même la sélection d un simple paquetage de la distribution pour une installation doit être effectuée manuellement. Il est conseillé de se baser sur un fichier créé avec l outil GUI, de façon à éviter des erreurs de construction ou de mise en place des éléments un par un qui pourraient provoquer des interruptions dans le processus d installation, ou bien des demandes d informations manquantes ou erronées dans la description de Kickstart. Dans tous les cas, après quelques tentatives, l erreur est presque toujours repérée, preuve de l efficacité de cette méthode d installation. Dans l Encadré 4, un exemple des grandes possibilités de Kickstart est présenté, en utilisant une vieille carte réseau non reconnue et un script post installation. lang de_de langsupport de_de keyboard de-latin1-nodeadkeys mouse generic3ps/2 timezone Europe/Berlin rootpw redhattestpasswort text install nfs --server= dir=/kickstart/fc1a device ethernet 3c509 -opts io=0x320, irq=7 # Carte Ethernet bootloader -uselilo -linear --location=mbr zerombr yes # Efface le MBR clearpart --all --initlabel part /boot --fstype ext3 --size 80 --asprimary part / --fstype ext3 --size 1 --grow \ --onpart hda2 --maxsize 2000 part /var/www --fstype ext2 --size part swap --size 512 auth --useshadow --enablemd5 network --bootproto=dhcp firewall --disabled skipx # Ignore la configuration de X # Sélection des paquets (résoud # automatiquement les dépendances) %packages Administration Printing Support lynx httpd %post # Les scripts CHROOT sont exécutés # dans l installation prête) # Introduction du nom du serveur: cat > /etc/resolv.conf <<EON search domain1.de domain2.de unterdomain. domain2.de nameserver nameserver EON # Activation de l accès aux disques durs DMA cat > /etc/sysconfig/harddisks <<EOF USE_DMA=1 MULTIPLE_IO=16 EIDE_32BIT=3 LOOKAHEAD=1 EXTRA_PARAMS=-X68 EOF chkconfig lpd off chkconfig httpd on mail -s Fin Install Ordinateur \ root@mailserver < /dev/null Encadré 4 : ks-avancé.cfg 69

252 Fedora Kickstart Red Hat Magazine 2004 N 3 Les informations relatives aux groupes de paquetages utilisés dans le fichier description, comme par Internet, sont disponibles dans le fichier : /kickstart/fc1ared Hat/base/comps Il est important d observer que l Installer de Red Hat n effectue que l installation de paquetages signés électroniquement Red Hat. Tous les paquetages tiers doivent être installés dans la section %post au moyen de la commande rpm. C est-à-dire qu il permet d obtenir une installation de base toujours stable. Préparation d une disquette de démarrage Pour créer une disquette de démarrage, insérez le premier CD de Fedora dans le lecteur de CD-ROM approprié et une disquette 1,44 formatée dans le premier lecteur de disquettes de l ordinateur. Tapez ensuite les commandes suivantes : #mount /mnt/cdrom #dd if=/mnt/cdrom/images/bootdisk.img \ of=/dev/fd0 #umount /mnt/cdrom De cette façon, une image générique pour les installations a été écrite sur disquette. Une telle disquette pourra par conséquent être utilisée pour les installations standard de Linux avec une base réseau, ou même pour les installations automatiques de Kickstart. Pour lancer automatiquement le mode Kickstart linuxks, montez la disquette qui vient d être mentionnée en tapant : #mount /mnt/floppy Suivez la méthode appropriée parmi les deux rapportées cidessous : 1. Fichier Kickstart sur disquette (basé sur disquette) En utilisant l éditeur de texte désiré, modifiez les deux lignes suivantes dans le fichier /mnt/floppy/syslinux.cfg prompt 0 default linux ks=floppy 2. Fichier Kickstart en réseau (basé sur réseau) Modifiez les deux lignes suivantes dans prompt 0 default linux ks A la fin de cette opération, il sera possible de copier le fichier de configuration de Kickstart de la disquette dans le fichier /mnt/floppy/ks.cfg Daemontez de nouveau la disquette en tapant : #umount /mnt/floppy Préparation d un CD-ROM de lancement Dans le cas où les drivers réseau nécessaires pour l installation ne seraient pas compatibles avec une disquette, nous vous conseillons d utiliser un CD-ROM de lancement. Mastérisez le fichier image ISO boot.iso, disponible dans le même répertoire de la disquette de démarrage, sur un CD vierge et activez ensuite le lancement à partir du CD-ROM dans le BIOS de l ordinateur à installer. Il suffit de taper linuxks pour activer le mode Kickstart. Il est conseillé de ne pas modifier le fichier syslinux.cfg pour le lancement automatique, parce qu il arrive souvent d oublier les CD-ROM dans le lecteur et cela conduirait à une nouvelle installation à chaque démarrage. Pour remédier au problème, surtout dans les cas d installations importantes, il est utile d envoyer un message à la fin du processus d installation qui indique à l administrateur sur quels ordinateurs l installation a déjà été effectuée. Lancement du programme d installation par l intermédiaire de PXE PXE est sans doute la façon la plus élégante pour exécuter d importantes installations en réseau. Il est particulièrement indiqué comme protocole pour les nombreuses cartes réseaux installées dans les ordinateurs d entreprises. PXE est en mesure de charger le programme d exécution de Fedora, directement à partir du réseau, en évitant par conséquent l utilisation d un support de lancement. Il est aussi possible d inclure des options au lancement qui permettent à l utilisateur d effectuer le rétablissement automatique du système. Puisqu il n est pas possible dans cet article d illustrer en détail l environnement PXE, nous vous renvoyons sur le site Kickstart.html qui contient un article intéressant de Alf Wachsmann avec des instructions détaillées sur l utilisation de Kickstart. Procédure d installation Après avoir inséré le support et démarré l ordinateur, Fedora commence par lancer l Installer Anaconda. En mode Kickstart avec configuration basée sur réseau, Kickstart tente avant tout d obtenir sa propre adresse IP au moyen d une requête DHCP et ensuite de charger le fichier de description correspondant à partir du serveur. Si cette procédure est exécutée correctement, la configuration de base peut être estimée complète. Pendant l installation, il est possible de tenir sous contrôle l image normale d installation sur la console 1 (ALT+F1). D autres fonctions de l Installer sont, quoi qu il en soit, disponibles à partir d une phase déterminée du processus d installation. Sur la console 2 (ALT+F2) il sera possible de trouver une console Bash pour la récolte d informations pour le debugging. La console 3 permet de relever d éventuels problèmes hardware car c est souvent ici que sont visibles les modules du kernel. C est pourquoi, en cas de problèmes 70

253 Fedora Kickstart Red Hat Magazine 2004 N 3 durant l installation, il est utile de les contrôler via cette console. En outre, contrôlez toujours le fichier /var/log/messages dans le serveur approprié. En rappelant la commande : #tail-f /var/log/messages Il sera possible de visualiser «en live» et par conséquent de contrôler les commandes du processus d installation qui ont été exécutéés correctement et celles qui, inversement, présentent des problèmes. Par exemple, le manque de réception de signaux DHCP ou NFS venant de l ordinateur client est attribuable à un problème hardware sur le réseau. Le paquetage sniffer tcpdump permet également, par exemple, de diagnostiquer des problèmes hardware s il ne relève aucun trafic du client. Boot à partir du CD-ROM/Disquette DHCP: Détermination de la configuration de réseau NFS: Montage du répertoire /kickstart Interprétation de la configuration de Kickstart Partitionnement et formatage du disque dur %pre-script #showmount -e <Adresse IP du serveur> Il est toujours possible de visualiser tous les partages NFS du serveur intéressé. Le problème est presque toujours dû à des erreurs d introduction contenues dans ces partages. Un autre type d erreur très fréquemment rencontré dans les installations de Kickstart est une syntaxe incorrecte dans le fichier de description, qui provoque une interruption du processus d installation ou bien également, dans bien des cas, une erreur d un script python. Ces erreurs se trouvent presque toujours dans la description de base du système plutôt que dans les scripts %pre ou %post. Par conséquent, la meilleure solution consiste à effectuer une comparaison avec les scripts déjà contrôlés et corrects. Si quelques scripts ont été créés manuellement avec la GUI, il sera possible de résoudre encore plus rapidement les problèmes éventuels grâce à la familiarité acquise. Installation de paquetages séparés Sur des groupes d ordinateurs installés avec Kickstart, il pourrait être nécessaire d installer par la suite de nouvelles versions de logiciels. Dans ce but, utilisez l outil de gestion des paquetages RPM, lesquels peuvent être installés dans le script %post. Les paquetages RPM permettent d effectuer des personnalisations complexes qu il sera possible par la suite, de supprimer au moyen des commandes standard, ainsi que d ajouter quelques utilisateurs ou de créer un profil pour des activités déterminées. L Encadré 5 illustre un exemple pour un fichier spec qui permet d ajouter un utilisateur qui pourra être supprimé à n importe quel moment. Le but de l exemple est de contrôler à distance un numéro vert. Pour exécuter cette opération, il a été fait référence à un script log dans une archive tar du fichier spec. L installation des paquetages RPM avec le script -%post de Kickstart permet d étendre également l accès à tous les autres ordinateurs. Summary: RemoteSupportUser Name: remotesupport Version: 0.1 Installation et configuration des paquetages Release: 1 License: GPL Séquence d installation Kickstart. Sources d erreur %post-script et redémarrage Les partages erronés NFS représentent une source d erreur bien connue dans les installations automatiques, puisqu ils ne permettent pas à l hôte d accéder aux fichiers de configuration et de distribution de Kickstart. Avec la commande : Group: System Environment/Base Source0: %{name}-%{version}.tar.gz Buildroot: %{_tmppath}/%{name}-%{version}- buildroot Packager: Frederik Bijlsma <frederik@killesberg.org> Provides: remotesupportuser 71

254 Fedora Kickstart Red Hat Magazine 2004 N 3 Requires: /bin/mail BuildArch: noarch %description NULL %prep %setup -q %build #empty %install rm -rf %{buildroot} mkdir -p %{buildroot}/home/remotesupportuser install -m 0755.logrc %{buildroot}/home/ remotesupportuser install -m 0755.bash_profile %{buildroot}/ home/remotesupportuser %clean rm -rf %{buildroot} %pre userdel remotesupportuser >/dev/null 2>&1 userdel `awk -F: $3 == «9993» /etc/passwd awk -F: { print $1 } ` >/dev/null 2>&1 Conclusion Le présent article a décrit une installation Kickstart basée réseau, reposant sur un serveur DHCP fonctionnel et un serveur NFS disposant des fichiers de description Kickstart et des supports d installation. Puisque beaucoup d entreprises utilisent déjà ces deux types de serveurs au sein de leurs réseaux, l utilisation de Kickstart ne devrait pas se révéler trop dispendieuse, excepté les quelques modifications nécessaires à apporter. L utilisation de Kickstart est recommandée lorsqu il est nécessaire d installer simultanément de nombreux ordinateurs comme, par exemple, pour les clusters. Avec un réseau très rapide, il est possible d installer en l espace d une heure de nombreuses machines, automatiquement ou individuellement. Après avoir acquis un peu de pratique, il sera possible d utiliser Kickstart pour diverses raisons, par exemple pour installer de grands clusters ou pour rétablir le poste de travail de l ordinateur de la secrétaire, sans devoir payer des techniciens qui généralement réclament une compensation supplémentaire pour ces opérations. En cas de problème avec l utilisation de Kickstart, consultez la mailing list à l adresse Naturellement, il est également possible de se référer au support technique, mais avec Kickstart vous en aurez rarement besoin. useradd -c «Remote Support User» -d /home/ remotesupportuser -g root -s /bin/bash -u 499 remotesupportuser >/dev/null 2>&1 %postun userdel remotesupportuser > /dev/null 2> / dev/null %files %defattr(-,root,root) %attr(0775,remotesupportuser,root) / home/remotesupportuser/scriptlog %attr(0755,remotesupportuser,root) / home/remotesupportuser/.bash_profile %attr(0755,remotesupportuser,root) / home/remotesupportuser/.logrc %changelog Encadré 5 : firmeuser.spec Frederik Bijlsma est consultant pour Red Hat, Stuttgart 72

255 Chapitre 11 Synchronisation de fichiers c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.1 Introduction Chapitre 11 Synchronisation de fichiers 11.1 Introduction Contexte : deux ou plusieurs machines qui ne peuvent pas partager de fichiers par NFS. Exemples : un ordinateur portable et une machine de bureau deux ordinateurs reliés par une liaison intermittente comme une liaison téléphonique PPP etc. La synchronisation manuelle est pénible à faire. Plusieurs logiciels automatisent la synchronisation. Reste à les lancer au bon moment (cf CRON) et à paramétrer ce que l on doit synchroniser. c T.Besançon (v ) Administration UNIX ARS Partie / 789

256 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Chapitre 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist RDIST est un programme de distribution de fichiers sur des machines distantes, sur la base des dates de modification des fichiers source ou des fichiers distants. De plus en plus livrée en standard avec les différents UNIX mais lui préférer quand même la version disponible à l URL « (anciennement : «ftp://ftp.usc.edu/pub/rdist/») c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist La commande «rdist» utilise un fichier de configuration appelé par défaut «distfile» ou «Distfile» Si le fichier ne s appelle pas «distfile» ou «Distfile», il faut utiliser l option «-f» : % rdist -f mon-distfile-a-moi remote.example.com: updating host remote.example.com... De nombreuses options sont disponibles. Cf la documentation. c T.Besançon (v ) Administration UNIX ARS Partie / 789

257 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Exemple 1 Objectif : mettre à jour du fichier «/tmp/fichier.txt» d une machine distante nommée «remote.example.com» à partir du fichier local «/tmp/fichier.txt» : Solution : fichier «Distfile» contenant : /tmp/fichier.txt -> remote.example.com install ; Utilisation et résultats : % rdist remote.example.com: updating host remote.example.com remote.example.com: /tmp/fichier.txt: installing remote.example.com: updating of remote.example.com finished c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist La mise à jour ci dessus est inconditionnelle. Elle ne fait pas de comparaison de date. Pour activer la vérification des dates de modification, il faut utiliser l option «-y». % rdist -y remote.example.com: updating host remote.example.com remote.example.com: updating of remote.example.com finished Notez les différence avec les résultats précédents. c T.Besançon (v ) Administration UNIX ARS Partie / 789

258 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Exemple 2 : macros Objectif : mettre à jour les fichiers «/var/tmp/fichier.txt» et «/var/tmp/fichier2.txt» des machines distantes nommées «remote.example.com», «remote2.example.com» et «remote3.example.com» à partir des fichiers locaux originaux «/tmp/fichier.txt» et «/tmp/fichier2.txt». Soit le fichier «Distfile» contenant les lignes suivantes : FILES = ( /tmp/fichier.txt /tmp/fichier2.txt ) HOSTS = ( remote.example.com remote2.example.com remote3.example.com ) ${FILES} -> ${HOSTS} install /var/tmp ; notify besancon ; c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist On constate : on utilise des macros : «FILES», «HOSTS» on met à jour des fichiers distants de paths différents des originaux on envoie un mail une fois la mise à jour faite c T.Besançon (v ) Administration UNIX ARS Partie / 789

259 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Possibilité de ne mettre à jour qu une machine du lot via l option «-m» : % rdist -m remote.example.com remote.example.com: updating host remote.example.com remote.example.com: /tmp/fichier.txt: installing remote.example.com: /tmp/fichier2.txt: installing remote.example.com: ( besancon ) remote.example.com: updating of remote.example.com finished c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Une seconde mise à jour donne : % touch /tmp/fichier.txt % rdist -y remote.example.com: updating host remote.example.com remote.example.com: /tmp/fichier.txt: updating remote.example.com: ( besancon ) remote.example.com: updating of remote.example.com finished Notez le mot «updating» au lieu de «installing». c T.Besançon (v ) Administration UNIX ARS Partie / 789

260 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Exemple 3 : directive special Soit le fichier «Distfile» contenant les lignes suivantes : /tmp/fichier.txt -> remote.example.com install ; special "uname -a" ; Son exécution donne : % rdist remote.example.com: updating host remote.example.com remote.example.com: /tmp/fichier.txt: installing remote.example.com: special "uname -a" remote.example.com: FreeBSD remote.example.com RC2 remote.example.com: updating of remote.example.com finished On constate qu une fois la mise à jour des fichiers réalisée, la commande spécifiée par «special» est exécutée sur la machine distante. c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist exemple 4 : essai à blanc L option «-n» essaye à blanc le scenario de mise à jour mais ne réalise pas la mise à jour en pratique. Avec le fichier «Distfile» de l exemple 1, on voit ainsi : % rdist -n updating host remote.example.com install -onochkgroup,nochkowner,younger /tmp/fichier.txt /tmp/fichier.txt c T.Besançon (v ) Administration UNIX ARS Partie / 789

261 11 Synchronisation de fichiers 11.2 Synchronisation de fichiers UNIX via rdist Exemple 5 : transport via SSH On peut utiliser SSH comme protocole de transport avec la machine distante au lieu de RSH. Avec le fichier «Distfile» de l exemple 1, on voit ainsi : % rdist -P /usr/local/bin/ssh remote.example.com: updating host remote.example.com Enter passphrase for key /users/sri/besancon/.ssh/id_dsa : XXXXXXXXXX remote.example.com: /tmp/fichier.txt: installing remote.example.com: updating of remote.example.com finished c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync Chapitre 11 Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync (en anglais Remote Synchronisation) RSYNC est un protocole plus efficace que RDIST. Par exemple, on ne transfère que les différences entre fichiers et non pas la totalité du fichier. Pas encore installé en standard. Se reporter à « c T.Besançon (v ) Administration UNIX ARS Partie / 789

262 11 Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync On utilise la commande de ces diverses façons : rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST rsync [OPTION]... [USER@]HOST:SRC DEST rsync [OPTION]... SRC [SRC]... DEST rsync [OPTION]... [USER@]HOST::SRC [DEST] rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST rsync [OPTION]... rsync://[user@]host[:port]/src [DEST] Il y a un mode de fonctionnement où un démon «rsyncd» est installé et répond à des requêtes authentifiées ou non. c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync Exemple Soit l arborescence «/tmp/exemple» à synchroniser : % ls -lr /tmp/exemple /tmp/exemple/: total 64 -rwxr-xr-x 1 besancon adm 211 Aug 26 17:53 fichier1* -rwxr-xr-x 1 besancon adm 211 Aug 26 17:53 fichier2* -rwxr-xr-x 1 besancon adm 211 Aug 26 17:53 fichier3* drwxr-xr-x 2 besancon adm 182 Aug 26 17:54 repertoire1/ /tmp/exemple/repertoire1: total 16 -rwxr-xr-x 1 besancon adm 211 Aug 26 17:53 fichier4* c T.Besançon (v ) Administration UNIX ARS Partie / 789

263 11 Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync La synchronisation avec une autre machine appelée «remote.example.com» par la commande suivante : % rsync \ --stats \ --rsh=/usr/local/bin/ssh \ --rsync-path=/usr/local/bin/rsync \ --archive \ --compress \ --verbose \ --cvs-exclude \ \ /tmp/exemple \ besancon@remote.example.com:/tmp c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.3 Synchronisation de fichiers UNIX via rsync La commande précédente affiche : building file list... done exemple/ exemple/fichier1 exemple/fichier2 exemple/fichier3 exemple/repertoire1/ exemple/repertoire1/fichier4 Number of files: 6 Number of files transferred: 4 Total file size: 844 bytes Total transferred file size: 844 bytes Literal data: 844 bytes Matched data: 0 bytes File list size: 161 Total bytes written: 825 Total bytes read: 84 wrote 825 bytes read 84 bytes bytes/sec total size is 844 speedup is 0.93 c T.Besançon (v ) Administration UNIX ARS Partie / 789

264 11 Synchronisation de fichiers 11.4 Synchronisation de fichiers WINDOWS via FullSync.exe Chapitre 11 Synchronisation de fichiers 11.4 Synchronisation de fichiers WINDOWS via FullSync.exe Programme FULLSYNC pour Windows. « Synchronisation de fichiers entre disques locaux Synchronisation de fichiers entre disques locaux et réseau via FTP, SFTP, SMB Synchronisation unidirectionnelle sans effacement sur la destination Synchronisation unidirectionnelle exacte Synchronisation bidirectionnelle Programmation à la CRON c T.Besançon (v ) Administration UNIX ARS Partie / Synchronisation de fichiers 11.4 Synchronisation de fichiers WINDOWS via FullSync.exe c T.Besançon (v ) Administration UNIX ARS Partie / 789

265 Chapitre 12 SAMBA c T.Besançon (v ) Administration UNIX ARS Partie / SAMBA 12.1 Introduction Chapitre 12 SAMBA 12.1 Introduction Voir cours de Franck RUPIN. c T.Besançon (v ) Administration UNIX ARS Partie / 789

266 Chapitre 13 Systèmes d impression c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.1 Langage d impression Postscript Chapitre 13 Systèmes d impression 13.1 Langage d impression Postscript Langage créé par la société Adobe (« Dessin vectoriel. Le nom d un fichier Postscript se finit en général par le suffixe «.ps» ou «.eps». Système de coordonnées au sein d une page Postscript Format américain (dit letter) : 612 x 795 Format européen (dit a4) : 595 x 842 c T.Besançon (v ) Administration UNIX ARS Partie / 789

267 13 Systèmes d impression 13.1 Langage d impression Postscript Langage de description de page, fonctionnant avec une stack (pile). Par exemple peut se coder : forme sub add forme 1 6 add 5 sub forme neg add add etc. ce qui donne avec la première forme : sub add Un document à imprimer = un programme à exécuter c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.1 Langage d impression Postscript Le contenu d un fichier Postscript commence par les 2 premiers caractères «%!». Les fichiers Postscript destinés à être inclus dans d autres documents sont dits Encapsulated Postscript (ou EPSF) et commencent par une ligne du genre : %!PS-Adobe-2.0 EPSF-1.2 suivie d autres lignes de commentaires actifs : %%Creator:Adobe Illustrator(TM) 1.0b2- %%Title:golfer art+ %%CreationDate:1/6/87 9:32 AM %%DocumentFonts:Helvetica-Bold %%BoundingBox: dont «%%BoundingBox:» qui détermine les dimensions du dessin. c T.Besançon (v ) Administration UNIX ARS Partie / 789

268 13 Systèmes d impression 13.1 Langage d impression Postscript Par exemple, le code suivant : %! /Times-Roman findfont 40 scalefont setfont moveto (TEST DE L IMPRIMANTE) show moveto (T.BESANCON) show showpage TEST DE L IMPRIMANTE T.BESANCON donne, une fois imprimé, la page suivante : c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.1 Langage d impression Postscript Les dessins en Postscript peuvent être complexes : Poids de ce dessin vectoriel (par tête) : octets, ce qui est faible par rapport à du bitmap c T.Besançon (v ) Administration UNIX ARS Partie / 789

269 13 Systèmes d impression 13.1 Langage d impression Postscript Un document à imprimer = un programme à exécuter La partie logicielle qui exécute le fichier Postscript est un interpréteur Postscript. L interpréteur Postscript le plus connu est ghostscript. Cf « Initialement disponible sur UNIX, il est maintenant disponible sur Windows et sur Macintosh sous une forme avec interface graphique : «ftp://ftp.lip6.fr/pub/gnu/ghostview/» (GUI UNIX) « (GUI pour UNIX) « (GUI pour Windows) « (GUI pour Macintosh) c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.1 Langage d impression Postscript L intérêt de ghostscript est : visualiser des fichiers Postscript comme les documentations convertir des fichiers Postscript en d autres formats : FAX PDF PCL pour imprimante PC etc. Mais la principale utilisation de ghostscript doit être certainement maintenant sur Linux où il sert à convertir du Postscript en langage PCL qui est compris par les imprimantes PC. c T.Besançon (v ) Administration UNIX ARS Partie / 789

270 13 Systèmes d impression 13.1 Langage d impression Postscript Quelques utilisations intéressantes : calculer la BoundingBox d une figure Postscript : gs -sdevice=bbox fichier.ps afficher au format A4 : gs -spapersize=a4 fichier.ps convertir du Postscript en PDF au format A4 : ps2pdf13 -spapersize=a4 fichier.ps (ps2pdf13 est un shell script construit autour de gs avec les bonnes options) c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.1 Langage d impression Postscript Comment imprimer un fichier texte sur une imprimante Postscript? Réponse : après l avoir converti en Postscript Quelques outils : outil a2ps, cf « outil gnu enscript, cf « c T.Besançon (v ) Administration UNIX ARS Partie / 789

271 13 Systèmes d impression 13.1 Langage d impression Postscript Comment imprimer plusieurs pages côte à côte (format dit N up)? Réponse : convertir en fichier Postscript «normal» le fichier original puis regrouper les pages sur la même page via un autre code Postscript Quelques outils : outil a2ps, cf « outil mpage, cf « c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.2 Langage d impression PCL Chapitre 13 Systèmes d impression 13.2 Langage d impression PCL PCL Printer Command Language Langage de description de la page à imprimer. Développé par HP pour ses imprimantes. 6 versions de PCL : PCL 1 (années 1980), PCL 2 (années 1980), PCL 3 (1984), PCL 4 (1985), PCL 5 (HP Laserjet III), PCL 6 (HP Lasetjet 4000) Les commandes PCL sont des séquences d escape. Par exemple EcE&l3A (passe en papier letter). Pour convertir du Postscript en PCL, faire : gs -q -ssafer -sdevice=deskjet -sooutputfile=fichier.pcl -dnopause fichier.ps c T.Besançon (v ) Administration UNIX ARS Partie / 789

272 13 Systèmes d impression 13.3 Langage d impression PJL Chapitre 13 Systèmes d impression 13.3 Langage d impression PJL PJL Printer Job Language Language de contrôle de l impression des jobs. Par exemple : sélection du bac d entrée ou de sortie de papier impression recto verso taille du papier fichier PCL ou fichier Postscript etc. Exemple de commande : ESC%-12345X@PJL DEFAULTS DENSITY=5 Le logiciel ifhp associé à LPRng sait tirer pleinement parti du langage PJL. Cf « c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.4 L imprimante vintage Chapitre 13 Systèmes d impression 13.4 L imprimante vintage L imprimante «vintage» : imprimante matricielle etc. avec ruban à encre papier listing avec bande d entrainement sectionnable connexion par voie série à 9600 bauds, gestion du flux XON/XOFF c T.Besançon (v ) Administration UNIX ARS Partie / 789

273 13 Systèmes d impression 13.4 L imprimante vintage caractères normaux caractères gras par réécriture d un caractère une seconde fois sur lui-même : A = «A backspace A» = «A^HA» idem pour caractères soulignés A = «A backspace underscore» = «A^H_» peu ou pas de polices de caractères peu ou pas de possibilités de tailles variées de caractères documents au format texte uniquement pas de graphiques ou de dessin (sauf ASCII art) etc. Lundi 25 Juin :42:23 woman1.txt Page 1... "..:I: :.:...:II: :. ::.:I:.:II: ::.:.:.:I: :.:I::.:II: :.:.::.:.::II:: :.::..:::II:.: :.. :...:.:I :.. :...:.::.::.:... : :.:. :..: :I:.:..... : :.:..:.II:.:....: :.:...:.:I:.:.....:..:. :.. :....:. :.:..:.:I:.:.....:I::. :: :: :..:..:.:I:...:.:I:. :: ::.....:..:...:II:..:IIIM. ::. :...:.::.:::..:.AII:..::.. :I.::.: :.. :..:.:II:.:I:..:.::PBI X::..:.. : : :III:. :.:A PPF:...P.IP:: :: :I:.. ::......:.:II: A.. :.PB: :.:.::. : :.:IIIM: :. :.:.. :......I.::I:IIA ::....:.....:II.. :IA:.....:..:.: ::I:.. ::A:...:...:...:.::AA..:..:.... :II:I:. :A:...: :.. :..:::AMI:..:..... :III.::I II:.:...::::::::..:::AMV::.::....":IIMI::.. I:.. ::...::...:AII:: :.:.... IIMMI:.... V::. ::::...:AIIV:.: :IIMI:..:.:.V:.....:MI:.:: : :IMII:: ::.IA.....A...:::.:.. :.... I:I:.:..AMMA....AMIV::.. :... :..::::II:.I:.MIMMIMMMMMIMMIMV:..::.I. : :::I:.::IMMMMMMMMMMMMIMI...:IMI... :.... ".::.MMMI:MMMMMMMIMI. :IIMMII:. I I I. :.:.....::..IV".:I:IIIMIMMIM..:IMI::. :......:.::.. ::... :.::I:I:IMMMIA..II.:...: ::::...::.IIMII::.:.:..:..:III:. :: ::.:... :IIMI:.:....:..:I:"...:.: :.:::I:....IMII:.:....".::.:II:.:..: ::.:... ::II:.: :II:.:: :.::.I......: :......:.::. : ::I:......: ::....I:..... :.: I......: :..:...:I......:::I:......: :.. I......:::I:......: :.:.:... :: I : :..:.. : : :.:.:.... :......: :.:.::.... : ::..:...:... ::.:.:..... : :.:.....:.. :::.::.:... : ::......:. V:I::::: :: :.:: VI:I:::::...:. : :....I: VII:I:I:::.. :::, : :..:.:I:.: :.. VMIII:I::.. ::: :: :..:.MI: :MMIMIII:I:: :: : :.:.:MI: MMMMIMII I:. : :.:.:.MI: IMMMMIMMIMI. : :..IM: MMMMMMMMMI : :.:.:MI :::::. MIM:""" : ::.:.VII......::: ::. MIM : :.:.:.VI ::I"A:. MMV : :.:.VI......::I::.MV: : :..II: ::: AV. : :..VI:......:...:.AV. : :.:.:MAI:.:...:.:.:.:.AII:. I: :.:.VMMII:..:.:..:A:.:.. IA :.:.:VMMMMIMIMMIMI:.::. MAI :.:.:MMMIMIMMMIMI:..:. MIA: :.VMMMIMIIMI::.:... MIMI: ::.MMMIIMIIMI:::.. MII:.: ::VMMIMI:I::.:.. AI:..: :.VMIII:I::.:.. AI:...: VMIII:I:.... AI:...: VMIII::.....A:.. : :.. VMII::... A:... :: :.. "VMI::....:.... :...:....::.. VMI: :.:...:...::.. VI: : :::. V: :::....:....::.. V :::A...:....::.. : ::IA ::. : :.::IA :.::. : :..:.::IIA......:.::. : :.::I:OMA......:.::....: :...:I:IIMMA......::I:...:: :..::.:IIMIIMMMA......:I:... A:: :..:.::I:IMIMIMMMMA.....::I:.. :MI: :.:.::I:IMIMIIMIMMMA.....::I:... AI: :.:.::II:IMIIIMIMIMMMA.....::I:... :MI: ::.:I:IMIMIIIMIMIIMMMA......::I:... AI:.: ::.::I:IMIIMIMIMIMIMIMMA.....::I:.. MI: :..::IIMIMIMIIIIMMIIMMMMA....:::I:... MI: :.::I:IIMMIIMIMIMIMMMMV".....:::II:.. MI:: :..:::IIMIMIIMIMIIMMMM"......::III:.. II::.: :..IMMMIMMMMMM :.:IMI:.. II:I:: ::.:IMMMMMMMM: :..:::IIMII.. MI::.: :.::.::.MMMMM::.: :....:IMMI:: MII::.: :..:.. MMMI::.::.: :...:II:III III::.: :.:.... MII:I::.: :.:::...:: VII::.: :... VMI:I::.: ::.:..:.: VII::.:......:.::.. : :MMII:I::.: :: :... III:I:: :.:... :VNIMI:I::.: :.... c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.4 L imprimante vintage Résumé des caractéristiques des impressions sur ce type d imprimantes : connexion non réseau par voie série (plus tard par voie parallèle) imprimer = «cat rapport.txt > /dev/tty0a» Dans cette logique, un logiciel d impression est avant tout capable de gérer des voies séries. c T.Besançon (v ) Administration UNIX ARS Partie / 789

274 13 Systèmes d impression 13.5 L imprimante moderne Chapitre 13 Systèmes d impression 13.5 L imprimante moderne L imprimante moderne : photocopieur, imprimante réseau, scanner, fax c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.5 L imprimante moderne Caractéristiques : Photocopieur : codes d accès quotas de photocopies relevé des compteurs serveur web intégré : protection des accès, certificats HTTPS, etc. Imprimante réseau : configuration réseau minimale (adresse IP, netmask, routeur,...) configuration réseau avancée : ACL pour contrôler les accès d impression, d , de partage de fichiers disque dur local (pour stocker des polices supplémentaires, des logos, des documents fréquemment imprimés, etc.) c T.Besançon (v ) Administration UNIX ARS Partie / 789

275 13 Systèmes d impression 13.5 L imprimante moderne Caractéristiques (suite) : Scanner (vers formats TIFF ou PDF) avec envoi des fichiers numérisés par ou récupération par FTP des fichiers numérisés : logiciels spécifiques sur le poste de travail de l utilisateur, drivers TWAIN, etc. attention aux logiciels ne travaillant que sur un seul subnet ethernet! configuration des paramètres de messagerie électronique configuration d un annuaire LDAP d entreprise ou des contacts de l entreprise configuration de partages réseau pour accéder aux fichiers scannés stockés sur le photocopieur, configuration des ACL réseau pour FTP,... Système d exploitation bugs (exemple gestion LDAP sur photocopieur CANON couleur) disque dur + problèmes de disques durs licences logicielles (codes d activation, dongles, etc.) c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.5 L imprimante moderne Résumé des caractéristiques des impressions sur ce type d imprimantes : connexion réseau par TCP/IP protocoles réseau implémentés dans l imprimante imprimer = «dialogue selon des protocoles avec un hôte TCP/IP qui prend en charge un fichier au jargon spécifique à imprimer physiquement» Dans cette logique, un logiciel d impression est avant tout capable de dialoguer en réseau selon des protocoles spéciaux. c T.Besançon (v ) Administration UNIX ARS Partie / 789

276 13 Systèmes d impression 13.6 Scenarios d impressions possibles Chapitre 13 Systèmes d impression 13.6 Scenarios d impressions possibles Pleins de scenarios sont possibles dans le monde de l impression : c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.6 Scenarios d impressions possibles c T.Besançon (v ) Administration UNIX ARS Partie / 789

277 13 Systèmes d impression 13.6 Scenarios d impressions possibles c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.6 Scenarios d impressions possibles c T.Besançon (v ) Administration UNIX ARS Partie / 789

278 13 Systèmes d impression 13.6 Scenarios d impressions possibles c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.7 Mécanismes et protocoles d impression Chapitre 13 Systèmes d impression 13.7 Mécanismes et protocoles d impression Dans un environnement réel, les mécanismes d impression permettent aux utilisateurs de s affranchir : de la connaissance des noms techniques des périphériques ; du risque d impressions mélangées lorsque deux utilisateurs essayent d imprimer en même temps ; des détails matériels tels que l absence momentanée de papier ; de la nécessité d attendre que l impression en cours se termine ; etc. c T.Besançon (v ) Administration UNIX ARS Partie / 789

279 13 Systèmes d impression 13.7 Mécanismes et protocoles d impression Pour résoudre tous ces problèmes, il a été conçu des spouleurs (spoolers). Le principe en est simple : Les utilisateurs déposent leurs fichiers dans un répertoire convenu, à l aide de la «commande d impression». C est la requête d impression. Un démon système surveille ce répertoire (file d attente), en extrait un fichier, l imprime, puis extrait le suivant, l imprime, etc. Des commandes permettent aux utilisateurs de savoir ce qu il y a dans la file d attente et éventuellement de détruire une de leurs requêtes. Des commandes permettent à l administrateur de gérer ce mécanisme : création d une nouvelle file d attente pour une nouvelle imprimante ; autorisation ou interdiction des dépôts dans des files d attente ; autorisation ou interdiction des impressions ; redirection des travaux d impression d une imprimante à une autre imprimante ; etc. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.8 Situation logicielle en 2007 Chapitre 13 Systèmes d impression 13.8 Situation logicielle en 2007 Plusieurs logiciels : mécanisme LP (SOLARIS) obsolète mécanisme LPR obsolète mécanisme LPRng (LINUX, UNIX) « a tendance à devenir obsolète mécanisme CUPS (LINUX, UNIX, Windows 2000/XP/2003, MacOSX) basé sur IPP (Internet Printing Protocol) « a la côte c T.Besançon (v ) Administration UNIX ARS Partie / 789

280 13 Systèmes d impression 13.8 Situation logicielle en 2007 Principes globaux de tous ces mécanismes : machines clientes d un serveur d impression le serveur d impression a des queues d impression pour les diverses imprimantes fonctionalités de gestion des queues plus ou moins élaborées selon le protocole : LP < LPR < LPRng < CUPS c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP Chapitre 13 Systèmes d impression 13.9 Protocole d impression LP commandes du système d impression LP Commande Autorisation Description accept administrateur accepte les requêtes cancel utilisateur supprime une requête disable utilisateur désactive une imprimante enable utilisateur active une imprimante lp utilisateur place une requête dans une file lpadmin administrateur configuration lpmove administrateur change la destination d une requête lpsched administrateur le démon proprement dit lpshut administrateur arrête le démon lpstat utilisateur liste la file d attente reject administrateur refuse les requêtes c T.Besançon (v ) Administration UNIX ARS Partie / 789

281 13 Systèmes d impression 13.9 Protocole d impression LP Les interactions entre les différents composants du système LP sont résumées dans la figure suivante : lp lpmove accept/reject file d attente flle d attente lpstat enable/disable lpsched imprimante 1 imprimante 2 imprimante 3 c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP Destinations - Files d attente Les requêtes sont dirigées vers des destinations. Une destination correspond à un file d attente. Chaque file d attente peut être associée à : une imprimante isolée (cas le plus fréquent). C est le cas de l imprimante 1 dans l exemple ; un groupe d imprimantes : c est ce qu on nomme une classe. Les requêtes sont alors envoyées indifféremment sur n importe laquelle des imprimantes de la classe. C est le cas des imprimantes 2 et 3 dans l exemple. c T.Besançon (v ) Administration UNIX ARS Partie / 789

282 13 Systèmes d impression 13.9 Protocole d impression LP Il y a trois moyens de spécifier une destination, classés par ordre de priorité : 1 avec l option «-d» ; 2 avec la variable d environnement «LPDEST» ; 3 en ne nommant aucune destination : la destination par défaut est alors choisie. Lorsque l utilisateur tape la commande «lp», la requête est mémorisée dans la file d attente correspondant à la destination spécifiée. La mémorisation est autorisée si le robinet contrôlant l accès à la file est ouvert. L administrateur agit sur ce robinet avec les commandes «accept» et «reject». c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP La commande «lpstat» permet de visualiser le contenu des files d attentes. La commande «cancel» permet de retirer une requête de sa file d attente. Les requêtes dans les files d attente sont ensuite traitées par le démon «lpsched». Celui-ci surveille l état de toutes files d attente et les imprimantes. Lorsqu une imprimante a fini d imprimer, «lpsched» choisit la requête suivante dans la file, et l envoie sur l imprimante. L impression est autorisée si le robinet contrôlant l accès à une imprimante est ouvert. L administrateur, ou les utilisateurs, peuvent contrôler ce robinet avec les commandes «enable» et «disable». Lorsqu une destination est indisponible, l administrateur peut rerouter une requête ou l ensemble des requêtes situées dans une file d attente dans une autre. Il faut pour cela que le démon soit arrêté. c T.Besançon (v ) Administration UNIX ARS Partie / 789

283 13 Systèmes d impression 13.9 Protocole d impression LP L arrêt du démon «lpsched» est effectué par «lpshut». De manière générale, toute modification sur le système d impression doit se faire lorsque le démon est à l arrêt. L arrêt est brutal : les requêtes en cours d impression sont purement et simplement stoppées. Le redémarrage du démon provoquera à nouveau leur impression depuis le début. Enfin, la commande «lpadmin» est la boîte à outils de l administrateur. Elle permet de contrôler tous les constituants du système (hors robinets). c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP La commande «lp» permet de demander l impression d un ou de plusieurs fichiers : lp [-d destination] [-m] [-n nombre] [-o options] [-s] [-t titre] [-w] fichiers Les options sont : Option Signification -d spécifie une imprimante -m envoie un courrier lorsque l impression est finie -n demande l impression de plusieurs copies -o passe des options au script d impression -s n affiche pas l identificateur dans la file d attente -t imprime un titre sur la page d en-tête -w envoie un message lorsque l impression est finie c T.Besançon (v ) Administration UNIX ARS Partie / 789

284 13 Systèmes d impression 13.9 Protocole d impression LP Scripts d impression Lorsque «lpsched» lance une impression, il appelle en réalité un script shell appelé le script d interface. Ce script, nommé du nom de l imprimante, a pour fonction d imprimer la bannière et le fichier. Il reçoit en paramètres : 1 l identificateur de la requête dans la file d attente ; 2 le nom de l utilisateur qui a formulé la requête ; 3 le titre qu il a éventuellement indiqué ; 4 le nombre de copies à imprimer ; 5 les options éventuellement spécifiées par l option «-o» de la commande «lp» ; 6 et enfin une liste de fichiers dans la file d attente. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP La sortie standard de ce script est redirigée sur le fichier spécial correspondant à l imprimante, et la sortie d erreur est éventuellement transmise par courrier à l utilisateur. Dans le cas le plus simple, ce script génère une bannière et ne fait qu un «cat» du fichier sur la sortie standard pour effectuer l impression. Mais des scripts plus évolués permettent de reconnaître automatiquement le type du fichier et l imprimer en conséquence (PostScript, texte, etc.). Les options peuvent permettre de changer de fonte, de bac papier, de taille de page, etc. L utilisation de tels scripts rend ce système d impression particulièrement souple. Si beaucoup de scripts modèles sont fournis par le constructeur, la possibilité de les modifier et de les adapter est très importante pour utiliser pleinement les imprimantes. c T.Besançon (v ) Administration UNIX ARS Partie / 789

285 13 Systèmes d impression 13.9 Protocole d impression LP Ajout d une imprimante Lors de l ajout d une imprimante, il faut : avoir le bon cable (parallèle, série ou autre) ; créer le fichier spécial correspondant à l interface ; rendre «lp» propriétaire du fichier spécial ; changer les droits du fichier spécial pour que personne ne puisse y accéder autrement que par «lp» ; récapituler les paramètres de connexion (caractéristiques de la liaison) ; identifier le type de l imprimante et choisir en conséquence un script modèle s en approchant. Les scripts modèle sont en principe dans le répertoire : «/usr/spool/lp/model». choisir un nom pour l imprimante ; vérifier que le démon «lpsched» ne tourne pas et l arrêter éventuellement avec «lpshut». c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP Une fois cela fait, la commande «lpadmin» peut être appelée pour créer l imprimante : # lpadmin -pnom-de-l imprimante -mscript -vfichier-spécial avec : l option «-p» spécifie le nom de l imprimante ; l option «-m» spécifie le nom du script modèle qui sera utilisé comme script d interface. Le script modèle doit obligatoirement résider dans le répertoire des scripts modèles ; l option «-v» spécifie le fichier spécial dans «/dev». Cette commande place le script modèle dans le répertoire des scripts d interface (répertoire «/usr/spool/lp/interface»). c T.Besançon (v ) Administration UNIX ARS Partie / 789

286 13 Systèmes d impression 13.9 Protocole d impression LP Une fois ce script installé, il est possible, par le biais de la commande «stty», de modifier les paramètres de connexion s il s agit d une liaison série. Par exemple : # lpadmin -pps -mpostscript -v/dev/ps Une fois l imprimante créée, elle peut éventuellement devenir l imprimante par défaut. Pour cela, il faut exécuter : # lpadmin -dnom-de-l imprimante Il faut maintenant libérer l accès aux files d attente et à l imprimante. Pour cela, il faut utiliser les commandes : # accept nom-de-l imprimante # enable nom-de-l imprimante Après avoir redémarré le démon avec la commande «lpsched», vous pouvez à présent utiliser votre imprimante. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression 13.9 Protocole d impression LP Suppression d une imprimante Le retrait d une imprimante est effectué par la commande : # lpadmin -xnom-de-l imprimante c T.Besançon (v ) Administration UNIX ARS Partie / 789

287 13 Systèmes d impression 13.9 Protocole d impression LP Gestion des classes Une imprimante peut être directement créée dans une classe, ou peut être ajoutée a posteriori dans une classe. Pour cela, l option «-c» doit être spécifiée : création d une imprimante dans une classe : # lpadmin -pnom-de-l imprimante -mscript -vfichier-spécial -cn intégration d une imprimante existante dans une classe : # lpadmin -pnom-de-l imprimante -cnom-de-la-classe Pour supprimer une classe, il suffit d utiliser l option «-x» comme pour supprimer une imprimante. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Chapitre 13 Systèmes d impression Protocole d impression LPD Commandes du système d impression Commande Autorisation Description lpr utilisateur place une requête dans la file lprm utilisateur supprime une requête lpq utilisateur liste la file d attente lpc administrateur boîte à outils lpd administrateur le démon proprement dit c T.Besançon (v ) Administration UNIX ARS Partie / 789

288 13 Systèmes d impression Protocole d impression LPD Les interactions entre les différents composants du système d impression Berkeley sont résumées dans la figure suivante : lpr lpc enable lpc disable file d attente file d attente lpq lpd imprimante 1 imprimante 3 c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Les requêtes sont destinées à des file d attente. Il y a une file d attente par imprimante, et il n y a donc pas de possibilité de grouper des imprimantes comme dans le spouleur AT&T. Il y a trois moyens de spécifier une file d attente, classés par ordre de priorité : 1 avec l option «-P» ; 2 avec la variable d environnement «PRINTER» ; 3 en ne nommant aucune destination : la destination par défaut est alors choisie. Lorsque l utilisateur tape la commande «lpr», la requête est mémorisée dans la file d attente correspondant à l imprimante spécifiée. La mémorisation est autorisée si le robinet contrôlant l accès à la file est ouvert. c T.Besançon (v ) Administration UNIX ARS Partie / 789

289 13 Systèmes d impression Protocole d impression LPD L administrateur agit sur ce robinet avec la commande «lpc» (sous-commande «disable»). La commande «lpq» permet de visualiser le contenu des files d attentes. La commande «lprm» permet de retirer une requête de sa file d attente. Les requêtes dans la file d attente sont ensuite traitées par le démon «lpd». Celui-ci surveille les requêtes distantes et l état des files et des imprimantes. Lorsqu une imprimante a fini d imprimer, «lpr» choisit la requête suivante dans la file, et l envoie sur l imprimante. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Le fonctionnement du démon est très différent de celui de LP : requêtes réseau lpr lpd file d attente lpd lpd file d attente imprimante 1 imprimante 2 c T.Besançon (v ) Administration UNIX ARS Partie / 789

290 13 Systèmes d impression Protocole d impression LPD Le démon «lpd» est normalement inactif, à l écoute des requêtes venant des programmes «lpr» locaux ou des démons «lpd» d autres machines. Lorsqu un utilisateur lance la commande «lpr», «lpr» place la requête dans la file d attente, puis se connecte au démon «lpd» en lui demandant de surveiller la file d attente spécifiée. Sur cette requête, «lpd» génère un sous-processus pour imprimer toutes les requêtes de la file d attente. Ce sous-processus ne s arrête que lorsqu il n y a plus aucune requête en attente dans la file spécifiée. Il y a donc un sous-démon par file d attente non vide. Si la file d attente n est pas vide, mais qu aucun démon n est présent, on atteint le même effet que la commande «disable» avec le spouleur AT&T. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD La commande «lpc» est la boîte à outils de l administrateur. Elle permet de contrôler tous les robinets du système. C est une commande interactive qui dispose de sous-commandes. On peut également appeler directement une sous-commande (par exemple : «lpc up all»). Les différentes sous-commandes sont : Commande Effets sur... File Démon Autres abort arrêté démons interdits clean nettoyée disable désactivée lpr interdit down désactivée arrêté lpr interdit enable activée lpr autorisé exit termine lpc quit termine lpc restart redémarré start démarré démons autorisés status affiche l état du système stop arrêté démons interdits topq place un processus en tête de file up activée démarré lpr autorisé c T.Besançon (v ) Administration UNIX ARS Partie / 789

291 13 Systèmes d impression Protocole d impression LPD Fichier /etc/printcap Le fichier centralisant toutes les définitions d imprimantes est «/etc/printcap». Ce fichier contient des champs «code=valeur». Par exemple : lp ps postscript PostScript:\ :lp=/dev/ps:sd=/usr/spool/lpd/ps:\ :lf=/usr/spool/lpd/ps/ps-log:\ :mx#0:sf:sb:\ :if=/usr/local/lib/psif: L imprimante par défaut s appelle toujours «lp». c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Les options sont, dans cet exemple : lp=/dev/ps nom du fichier spécial ; sd=/usr/spool/lpd/ps nom du répertoire contenant la file d attente ; lf=/usr/spool/lpd/ps/ps-log nom du fichier contenant les erreurs ; mx#0 pas de limitation de taille des fichiers imprimés ; sf, sb pas de bannière, pas de page de fin ; if=/usr/local/lib/psif filtre d impression pour les fichiers texte ; c T.Besançon (v ) Administration UNIX ARS Partie / 789

292 13 Systèmes d impression Protocole d impression LPD Ajout d une imprimante Lors de l ajout d une imprimante, il faut : avoir le bon cable (parallèle, série ou autre) ; créer le fichier spécial correspondant à l interface ; changer les droits du fichier spécial pour que personne ne puisse y accéder autrement que par lpr ; récapituler les paramètres de connexion ; choisir un nom pour l imprimante ; L ensemble des paramètres (y compris les paramètres de connexion, s il s agit d une liaison série) doivent être placés dans le fichier «/etc/printcap». Le répertoire correspondant à la file d attente doit être créé manuellement. Son nom doit correspondre au nom installé dans «/etc/printcap». Le propriétaire et le groupe doivent être «daemon». Les droits doivent être lecture, écriture et exécution pour le propriétaire et le groupe, lecture et exécution pour les autres. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Impression à distance La commande «lpr» permet également d imprimer des fichiers sur des imprimantes distantes. Pour mettre en place une impression à distance, il faut placer les informations suivantes dans le fichier «/etc/printcap» sur la machine cliente : # # l imprimante qui est sur cendrillon # lp ps postscript PostScript:\ :rm=cendrillon:\ :rp=ps:\ :sd=/usr/spool/lpd/ps: c T.Besançon (v ) Administration UNIX ARS Partie / 789

293 13 Systèmes d impression Protocole d impression LPD Les options sont : rm=cendrillon Nom de la machine distante ; rp=ps Nom de l imprimante sur la machine distante ; sd=/usr/spool/lpd/ps il faut un répertoire local, car la machine distante peut ne pas être disponible au moment où l utilisateur local lance la commande «lpr». La machine distante, quant à elle, doit autoriser les requêtes d impression. Ceci se fait en mettant le nom de la machine cliente dans un des fichiers : «/etc/hosts.equiv» «/etc/hosts.lpd» c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPD Protocole d impression LPD par la pratique Contexte : une imprimante réseau supportant directement le protocole LPD. L imprimante a le nom DNS «hp.example.com». L imprimante sera connue du système d impression sous le nom de queue «hp». La définition de la queue d impression LPD se fera dans le fichier «/etc/printcap» de la façon suivante : hp:\ :lp=:\ :mx#0:\ :rp=raw:\ :rm=hp.example.com:\ :lf=/var/spool/lpd/hp/log:\ :sd=/var/spool/lpd/hp: c T.Besançon (v ) Administration UNIX ARS Partie / 789

294 13 Systèmes d impression Protocole d impression LPRng Chapitre 13 Systèmes d impression Protocole d impression LPRng LPRng = LPR New Generation Amélioration de LPD. Voir annexe. c T.Besançon (v ) Administration UNIX ARS Partie / Systèmes d impression Protocole d impression LPRng Protocole d impression LPRNG par la pratique Contexte : une imprimante réseau supportant directement le protocole LPD. L imprimante a le nom DNS «hp.example.com». L imprimante sera connue du système d impression sous le nom de queue «hp». La définition de la queue d impression LPRNG se fera dans le fichier «/etc/printcap» de la façon suivante : hp: :cm=laserjet HP4050 :lp=raw@hp.example.com :sh :mc=0 :mx=0 :ifhp=model=hp4050 :filter=/usr/libexec/filters/ifhp :sd=/var/spool/lpd/%p :lf=/var/spool/lpd/%p/log :af=/var/spool/lpd/%p/acct :server c T.Besançon (v ) Administration UNIX ARS Partie / 789

295 13 Systèmes d impression Protocole d impression IPP / CUPS Chapitre 13 Systèmes d impression Protocole d impression IPP / CUPS CUPS = Common Unix Printing System c T.Besançon (v ) Administration UNIX ARS Partie / 789

296 Chapitre 14 Monitoring de systèmes c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.1 Logiciels de dessin de réseaux Chapitre 14 Monitoring de systèmes 14.1 Logiciels de dessin de réseaux Plusieurs logiciels disponibles mais incompatibles : VISIO, disponible dans Microsoft Office sous Windows : « DIA, disponible sur UNIX ou Windows : « c T.Besançon (v ) Administration UNIX ARS Partie / 789

297 14 Monitoring de systèmes 14.1 Logiciels de dessin de réseaux Bibliothèque de symboles CISCO dans DIA : c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.2 Logiciels de tracés de courbes Chapitre 14 Monitoring de systèmes 14.2 Logiciels de tracés de courbes Objectif : visualiser certains aspects système : pagination débits réseau utilisation de jetons logiciels températures de salles machines etc. Avec quel(s) outil(s) tracer les mesures réalisées? GNUPLOT MRTG RRDTOOL etc. c T.Besançon (v ) Administration UNIX ARS Partie / 789

298 14 Monitoring de systèmes 14.3 GNUPLOT Chapitre 14 Monitoring de systèmes 14.3 GNUPLOT Site « Aussi disponible sur Windows. Exemple (tracé d une donnée en fonction du temps) : 500 "data" using 1: / / / / / / / / / /29 c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.3 GNUPLOT Gnuplot utilise un langage scriptable pour dessiner les courbes. Exemple de données : Script : set terminal png set output "data.png" set timefmt "%Y%m%d" set xdata time set format x "%Y\n%m/%d" set yrange [0:500] plot "data" using 1:2 with linespoints c T.Besançon (v ) Administration UNIX ARS Partie / 789

299 14 Monitoring de systèmes 14.3 GNUPLOT Image «data.png» obtenue par «gnuplot consommation.gnuplot» : 500 "data" using 1: / / / / / / / / / /29 c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.4 MRTG Chapitre 14 Monitoring de systèmes 14.4 MRTG Site « A completer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

300 14 Monitoring de systèmes 14.4 MRTG Exemples c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.5 RRDTOOL Chapitre 14 Monitoring de systèmes 14.5 RRDTOOL Site « Attention : version 2.x buggée rester sur 1.x A completer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

301 14 Monitoring de systèmes 14.5 RRDTOOL Exemples c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.5 RRDTOOL c T.Besançon (v ) Administration UNIX ARS Partie / 789

302 14 Monitoring de systèmes 14.5 RRDTOOL c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.5 RRDTOOL Principe Fichier de données d extension «.rrd». RRD signifie Round Robin Database N slots Une fois les N slots remplis, on vire la valeur la plus vieille et on décale DONNEES 27 DONNEES 26 DONNEES 25 DONNEES 24 DONNEES 23 DONNEES 22 DONNEES 27 DONNEES 26 DONNEES 25 DONNEES 24 DONNEES 23 DONNEES 22 c T.Besançon (v ) Administration UNIX ARS Partie / 789

303 14 Monitoring de systèmes 14.5 RRDTOOL Possibilité de «consolider» des données. Par exemple : échantillonnage toutes les 5 minutes consolidation : 1 donnée par heure consolidation : 1 donnée par jour consolidatoin : 1 donnée par semaine Objectif des consolidations : obtenir des graphes sur différentes périodes de temps sans avoir à mémoriser toutes les données échantillonnées de façon à avoir un fichier de données de taille qui reste raisonnable : graphe des N dernières heures graphe des N derniers jours graphe des N dernières semaines graphe des N derniers mois c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.5 RRDTOOL Initialisation du fichier «.rrd» : A completer... Ajout de données : A completer... Graphe des données : A completer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

304 14 Monitoring de systèmes 14.6 Logiciels de surveillance Chapitre 14 Monitoring de systèmes 14.6 Logiciels de surveillance Plusieurs solutions : produits maison logiciels clef en main framework permettant des adaptations maison etc. Dans la dernière catégorie : NAGIOS CACTI Big Brother, Big Sister HP OpenView BMC Patrol etc. c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Chapitre 14 Monitoring de systèmes 14.7 NAGIOS Site « Principe : la «console» NAGIOS surveille des clients via des «agents logiciels» NAGIOS : Console Console Console indirecte host 1 host 2 host 1 host 2 c T.Besançon (v ) Administration UNIX ARS Partie / 789

305 14 Monitoring de systèmes 14.7 NAGIOS La console NAGIOS peut avoir une interface web (serveur web APACHE + scripts CGI) mais non obligatoire. Interface web simple. Le gros du travail : définir le réseau : liste des définitions des machines liste des définitions des services à surveiller sur les machines installer les agents NAGIOS c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Exemples c T.Besançon (v ) Administration UNIX ARS Partie / 789

306 14 Monitoring de systèmes 14.7 NAGIOS c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS c T.Besançon (v ) Administration UNIX ARS Partie / 789

307 14 Monitoring de systèmes 14.7 NAGIOS c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Objets NAGIOS host hostgroup service servicegroup contact contactgroup timeperiod command servicedependency (dépendance entre services) servicescalation hostdependency (dépendance entre machines) hostescalation hostextinfo (extended host information : icône, URL) serviceextinfo (extended service information : icône, URL) Il est possible d avoir des squelettes pour faciliter les définitions des objets en regroupant dans un squelette des caractéristiques communes. c T.Besançon (v ) Administration UNIX ARS Partie / 789

308 14 Monitoring de systèmes 14.7 NAGIOS Définition d un template Cas d un objet host : define host{ name generic-host ; Name of template register 0 ; DON T REGISTER ; IT IS JUST A TEMPLATE } notifications_enabled 1 ; Host notifications are enabled event_handler_enabled 1 ; Host event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status information across program restarts retain_nonstatus_information 1 ; Retain non-status information across program restart notification_period 24x7 ; Send host notifications at any time c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Possibilité de template imbriqué : define host { name server ; Name of template use generic-host ; Inherits from generic-host register 0 ; DON T REGISTER ; IT IS JUST A TEMPLATE } check_period 24x7 ; By default, Linux hosts are checked round the c max_check_attempts 10 ; Check each Linux host 10 times (max) check_command check-host-alive ; Default command to check Linux hosts notification_period workhours notification_interval 120 ; Resend notification every 2 hours notification_options d,u,r ; Only send notifications for specific host state contact_groups admins ; Notifications get sent to the admins by default c T.Besançon (v ) Administration UNIX ARS Partie / 789

309 14 Monitoring de systèmes 14.7 NAGIOS Définition d un host (machine) define host{ use server } host_name alias address mail.example.com smtp.example.com mail.example.com Etats d un host : «OK» «DOWN» «UNREACHABLE» «RECOVERING» c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Définition d un service define service { use host_name service_description check_command } define service { use host_name service_description check_command } local-service mail.example.com SSH check_ssh local-service mail.example.com CAMCONTROL check_nrpe!check_camcontrol_da0 Etats d un service : «OK» «WARNING» «CRITICAL» «UNKNOWN» «RECOVERING» c T.Besançon (v ) Administration UNIX ARS Partie / 789

310 14 Monitoring de systèmes 14.7 NAGIOS Définition d une commande Un service NAGIOS fait appel à une commande NAGIOS. Commande NAGIOS = plugin NAGIOS = agent NAGIOS Nombreuses commandes fournies. define command { command_name check_ssh command_line $USER1$/check_ssh -H $HOSTADDRESS$ } define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } Facile d ajouter ses commandes : define command { command_name check-netapp-globalstatusmsg command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C public -o } c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Plusieurs protocoles de communication entre NAGIOS et ses plugins. NAGIOS external command file check_xyz (plugin) check_by_ssh (plugin) check_nrpe (plugin) check_snmp (plugin) NSCA (daemon) service sshd (daemon) nrpe (daemon) snmpd (daemon) send_nsca (client) check_xyz (plugin) check_xyz (plugin) result of service check client client client client client c T.Besançon (v ) Administration UNIX ARS Partie / 789

311 14 Monitoring de systèmes 14.7 NAGIOS NRPE : NAGIOS Remote Plugin Executor port TCP 5666 monitoring actif : NAGIOS est à l initiative des tests NSCA : NAGIOS Service Check Acceptor monitoring passif ; NAGIOS reçoit des résultats de tests dont il n est pas l initiateur c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Il est facile d écrire un plugin : #!/bin/sh if [... ] then # condition OK echo "OK - blabla" exit 0 fi if [... ] then # condition WARNING echo "WARNING - blabla" exit 1 fi if [... ] then # condition ERROR echo "CRITICAL - blabla" exit 1 fi if [... ] then # condition UNKNOWN echo "UNKNOWN - blabla" exit 3 fi N importe quel langage de programmation peut convenir. c T.Besançon (v ) Administration UNIX ARS Partie / 789

312 14 Monitoring de systèmes 14.7 NAGIOS Définition d un contact define contact{ contact_name alias service_notification_period host_notification_period service_notification_options host_notification_options service_notification_commands host_notification_commands } nagios-admin Nagios Admin 24x7 24x7 w,u,c,r d,r notify-by- host-notify-by- nagios-admin@example.com c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.7 NAGIOS Notification via From nagios@example.com Fri Aug 3 12:10: Date: Fri, 3 Aug :10: (CEST) From: nagios@example.com To: nagios-admin@example.com Subject: ::NAGIOS:: ** PROBLEM alert - mail.example.com/camcontrol is CRITICAL ** ***** Nagios 2.6 ***** Notification Type: PROBLEM Service: CAMCONTROL Host: mail.example.com Address: mail.example.com State: CRITICAL Date/Time: Fri Aug 3 12:10:02 CEST 2007 Additional Info: CAMCONTROL ALERT :09:28 da0 [COMPAQ RAID 1 VOLUME reco] c T.Besançon (v ) Administration UNIX ARS Partie / 789

313 14 Monitoring de systèmes 14.7 NAGIOS Notification via (suite) From Fri Aug 3 12:24: Date: Fri, 3 Aug :25: (CEST) From: nagios@example.com To: nagios-admin@example.com Subject: ::NAGIOS:: ** RECOVERY alert - mail.example.com/camcontrol is OK ** ***** Nagios 2.6 ***** Notification Type: RECOVERY Service: CAMCONTROL Host: mail.example.com Address: mail.example.com State: OK Date/Time: Fri Aug 3 12:25:02 CEST 2007 Additional Info: CAMCONTROL OK :24:28 da0 [COMPAQ RAID 1 VOLUME OK] c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.8 NAGIOS + OREON Chapitre 14 Monitoring de systèmes 14.8 NAGIOS + OREON L interface de NAGIOS n est pas très pratique. Possibilité d offrir une autre interface web : OREON Site « A completer... c T.Besançon (v ) Administration UNIX ARS Partie / 789

314 14 Monitoring de systèmes 14.9 CACTI Chapitre 14 Monitoring de systèmes 14.9 CACTI Site « A completer... c T.Besançon (v ) Administration UNIX ARS Partie / Monitoring de systèmes 14.9 CACTI Exemples c T.Besançon (v ) Administration UNIX ARS Partie / 789

315 Chapitre 15 Mécanisme d authentification réseau : /etc/passwd c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : /etc/passwd 15.1 Introduction Chapitre 15 Mécanisme d authentification réseau : /etc/passwd 15.1 Introduction Voir dans le volume 2 la partie sur «/etc/passwd» et «/etc/shadow». Problématique : comment gérer un réseau de machines qui n utiliseront que les fichiers «/etc/passwd» et «/etc/shadow»? c T.Besançon (v ) Administration UNIX ARS Partie / 789

316 15 Mécanisme d authentification réseau : /etc/passwd 15.2 Principe d une solution Chapitre 15 Mécanisme d authentification réseau : /etc/passwd 15.2 Principe d une solution Une solution : recopier depuis une machine A sur les autres machines les fichiers «/etc/passwd» et «/etc/shadow» recopie sur les autres machines via SCP (voir SSH) recopie périodique via CRONTAB n autoriser les changements de mot de passe que sur la machine A Quels sont les inconvénients de cette méthode? Quels sont les avantages de cette méthode? c T.Besançon (v ) Administration UNIX ARS Partie / 789

317 Chapitre 16 Mécanisme d authentification réseau : NIS c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.1 Introduction Chapitre 16 Mécanisme d authentification réseau : NIS 16.1 Introduction NIS Network Information Service Créé par SUN en 1985 Anciennement Yellow Pages certaines commandes ont un nom en «yp...» Version NIS+ vers 1992, radicalement différente (cf annexe) C est un protocole réseau d accès à des informations centralisées sur un ou plusieurs serveurs redondants. Utilisation la plus courante : partager la base des comptes UNIX. c T.Besançon (v ) Administration UNIX ARS Partie / 789

318 16 Mécanisme d authentification réseau : NIS 16.2 Architecture de NIS Chapitre 16 Mécanisme d authentification réseau : NIS 16.2 Architecture de NIS Architecture construite en mode client / serveur : D A T A Maitre D A T A D A T A Esclave 1 Esclave 2 Mise a jour push / pull D A T A D A T A D A T A D A T A D A T A Client 1 Client 2 Client 3 Client 4 c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.2 Architecture de NIS Caractéristiques : Communications réseau via RPC (Remote Procedure Call) Propagation des données (maps) du serveur maitre aux serveurs esclaves en mode pull ou en mode push. Propagation des maps complètes Seul le serveur maitre peut modifier les données Les serveurs esclaves diffusent les données sans pouvoir les modifier c T.Besançon (v ) Administration UNIX ARS Partie / 789

319 16 Mécanisme d authentification réseau : NIS 16.3 Données NIS maps NIS, DBM, ypcat, ypmatch Chapitre 16 Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch Les données manipulées par NIS : maps Les maps contiennent des couples (clef, valeur). Il n y a que le serveur NIS maître qui peut changer le contenu d une map. Une map est au format DBM (cf «man dbm») ; une map se compose de 3 fichiers : le fichier source le fichier de suffixe «.pag» le fichier de suffixe «.dir» c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch La commande «makedbm» permet de convertir le fichier source en les 2 fichiers constituant le DBM. % cat demo clef1 banane clef2 arbre % makedbm demo demo % ls -l demo -rw-r--r-- 1 besancon adm 23 Aug 15 11:56 demo -rw besancon adm 0 Aug 15 11:57 demo.dir -rw besancon adm 1024 Aug 15 11:57 demo.pag Dans le système NIS, les maps sont stockées sur le serveur maitre dans «/var/yp/nom-du-domaine-nis» : % cd /var/yp/nom-de-domaine-nis % ls -l passwd* -rw root other 4096 Nov 23 07:26 passwd.byname.dir -rw root other 8192 Nov 23 07:26 passwd.byname.pag -rw root other 4096 Nov 23 07:26 passwd.byuid.dir -rw root other 8192 Nov 23 07:26 passwd.byuid.pag c T.Besançon (v ) Administration UNIX ARS Partie / 789

320 16 Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch Les maps sont construites automatiquement à partir de tous les fichiers sources des maps : passwd.byname passwd.byuid /etc/hosts makedbm NIS MASTER hosts.byname hosts.byuid /etc/passwd Le fichier «/var/yp/makefile» automatise toutes les créations de maps et leur propagation aux serveurs esclaves (mode push). c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch Extrait de «/var/yp/makefile» :... hosts.time: $(B) -l $(DIR)/hosts $(CHKPIPE)) \ (awk BEGIN { OFS="\t"; } $$1!~ /^#/ { print $$1, $$0 } $(CHKPIPE)) \ $(MAKEDBM) $(B) - "updated [! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byname; [! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byaddr; [! $(NOPUSH) ]; then echo "pushed hosts"; fi... c T.Besançon (v ) Administration UNIX ARS Partie / 789

321 16 Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch La construction d une map se résume alors à (par exemple suite à une modification de /etc/hosts) : # vi /etc/hosts # cd /var/yp # make hosts updated hosts pushed hosts c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch La librairie DBM permet de créer des enregistrements de taille maximale 1024 octets : % man dbm SunOS/BSD Compatibility Library Functions dbm(3b) NAME dbm, dbminit, dbmclose, fetch, store, delete, firstkey, nextkey - data base subroutines The sum of the sizes of a key/content pair must not exceed the internal block size (currently 1024 bytes). Moreover all key/content pairs that hash together must fit on a single block. store will return an error in the event that a disk block fills with inseparable data. c T.Besançon (v ) Administration UNIX ARS Partie / 789

322 16 Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch Quelques noms de maps : passwd.byname, passwd.byuid, group.byname, group.bygid, publickey.byname, hosts.byaddr, hosts.byname, mail.byaddr, mail.aliases, services.byname, services.byservicename, rpc.bynumber, rpc.byname, protocols.bynumber, protocols.byname, networks.byaddr, networks.byname, netmasks.bymask, netmasks.byaddr, ethers.byname, ethers.byaddr, bootparams, auto.master, auto.home, auto.direct, auto.src dont les plus utiles sont : map «passwd» map «group» map «hosts» map «netgroup» c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.3 Données NIS : maps NIS, DBM, ypcat, ypmatch La commande «ypcat» permet de consulter une map NIS depuis n importe quel client. Syntaxe : «ypcat map-nis» La commande «ypmatch» permet de consulter la valeur d une ou plusieurs clefs dans une certaine map NIS depuis n importe quel client. Syntaxe : «ypmatch clef1 clef2... map-nis» c T.Besançon (v ) Administration UNIX ARS Partie / 789

323 16 Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Chapitre 16 Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Un client NIS doit se connecter à un serveur NIS. C est l action de binding. Le binding nécessite : de fournir un nom de domaine NIS, le domainname ; une machine se déclare comme membre du groupe servi par les serveurs NIS de préciser la méthode de localisation du serveur NIS : broadcast ou explicite c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Nom de domaine La commande activant le nom de domaine est domainname. Pour consulter le nom de domaine : «domainname» Pour configurer manuellement le nom de domaine : «domainname nom-du-domaine-nis» c T.Besançon (v ) Administration UNIX ARS Partie / 789

324 16 Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Configuration du domainname automatique au démarrage : Sur Solaris : renseigner le fichier «/etc/defaultdomain» Sur Linux : renseigner le variable «NISDOMAIN» du fichier «/etc/sysconfig/network» NETWORKING=yes FORWARD_IPV4=false HOSTNAME=pcars6.formation.jussieu.fr DOMAINNAME=formation.jussieu.fr GATEWAY= GATEWAYDEV=eth0 NISDOMAIN=real.world ATTENTION : sur LINUX, ne pas confondre avec la variable «DOMAINNAME» c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Réalisation du binding Un client NIS fait tourner le démon «ypbind» qui se connecte à un serveur NIS que l on trouve selon 2 méthodes possibles : découverte par broadcast ; c est le mode par défaut. Sur Solaris, «/usr/lib/netsvc/yp/ypbind -broadcast» En pratique il y a une map «ypservers» qui contient les noms des serveurs. Cf «/var/yp/binding/nom-de-domaine-nis/ypservers» demande de connexion explicite Sur Solaris faire : # ypbind -ypsetme # ypset nom-du-serveur-nis-voulu La commande «ypwhich» affiche le nom du serveur NIS utilisé. c T.Besançon (v ) Administration UNIX ARS Partie / 789

325 16 Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset On peut controler un peu quels sont les clients qui se bindent aux servers. Pour cela, remplir sur les serveurs esclaves et sur le serveur maitre le fichier «/var/yp/securenets». Il liste les machines autorisées, sous forme adresses et netmasks. Par exemple : Signification : seules les machines des réseaux « /16» et « /24» sont autorisées à se binder. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Consultation des maps Un client NIS doit indiquer quels maps il utilisera. La plus courante est la map «passwd» dont on indique l utilisation par l ajout d une ligne en fin de fichier «/etc/passwd» : +::65534:65534::: Signification de cette ligne supplémentaire (à vérifier sur chaque système car il existe des différences) : Tout champ renseigné de cette ligne + remplace le même champ de la map inconditionnellement sauf pour UID et GID. Pour UID et GID, les valeurs mentionnées s activeront si ces champs sont absents de la map (c est-à-dire quand la map est vérolée ce qui indique un problème de fichier source vérolé). c T.Besançon (v ) Administration UNIX ARS Partie / 789

326 16 Mécanisme d authentification réseau : NIS 16.4 Client NIS, domainname, ypbind, ypwhich, ypset Exemple : +:*LK*:65534:65534:::/usr/local/bin/tcsh Signification : le passwd chiffré des utilisateurs de la map passwd est «* LK*» l UID sera si l entrée de la map ne précise pas d UID le GID sera si l entrée de la map ne précise pas de GID le shell de login est mis automatiquement à «/usr/local/bin/tcsh» c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.5 Slave server NIS, ypserv, ypxfr Chapitre 16 Mécanisme d authentification réseau : NIS 16.5 Slave server NIS, ypserv, ypxfr Un serveur NIS esclave fait tourner plusieurs démons : ypserv ypbind Le démon «ypserv» est là pour répondre aux requêtes des client NIS qui se sont bindés sur lui. Le démon «ypbind» n est là que pour faire du serveur esclave un client NIS aussi (mais ce n est pas obligatoire). Il n est pas garanti que le serveur esclave soit client NIS de lui même. Il peut se binder sur un autre serveur NIS du même domaine. c T.Besançon (v ) Administration UNIX ARS Partie / 789

327 16 Mécanisme d authentification réseau : NIS 16.5 Slave server NIS, ypserv, ypxfr Un serveur esclave peut être down au moment où le serveur maitre fait un push des maps. besoin pour le serveur esclave de se resynchroniser avec le serveur maitre ; pull des maps de la part du serveur esclave Cela se fait au moyen de shell scripts lancés périodiquement via la crontab : 30 * * * * /usr/lib/netsvc/yp/ypxfr_1perhour 31 1,13 * * * /usr/lib/netsvc/yp/ypxfr_2perday 32 1 * * * /usr/lib/netsvc/yp/ypxfr_1perday Ces scripts récupérent plus ou moins de maps suivant la fréquence de leur lancement. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.5 Slave server NIS, ypserv, ypxfr Exemple de l un de ces shell scripts, «ypxfr_1perhour» : #! /bin/sh # ypxfr_1perhour.sh - Do hourly NIS map check/updates PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH export PATH ypxfr passwd.byname ypxfr passwd.byuid c T.Besançon (v ) Administration UNIX ARS Partie / 789

328 16 Mécanisme d authentification réseau : NIS 16.6 Master server NIS, ypxfrd, rpc.yppasswdd, yppasswd Chapitre 16 Mécanisme d authentification réseau : NIS 16.6 Master server NIS, ypxfrd, rpc.yppasswdd, yppasswd Un serveur NIS maître fait tourner plusieurs démons : ypserv ypbind ypxfrd rpc.yppasswdd Même rôle pour «ypserv» que pour un serveur esclave. Même rôle pour «ypbind» que pour un serveur esclave. Le démon «ypxfrd» assure les transferts de maps demandés par les serveurs esclaves (mode pull). (en UNIX, on rencontre souvent le mot xfr pour transfert) Le démon «rpc.yppasswdd» assure le changement des mots de passe. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.6 Master server NIS, ypxfrd, rpc.yppasswdd, yppasswd Avec NIS, un client NIS ne peut pas modifier le contenu d une map. Pour changer un mot de passe, on va émuler le changement du mot de passe sur le serveur maitre dans son fichier source («/etc/passwd») puis la reconstruction de la map passwd et sa transmission en totalité aux serveurs esclaves. Ce processus se réalise en utilisant la commande «yppasswd» qui demande les mots de passe à l utilisateur puis appelle «rpc.yppasswdd» sur le serveur maitre qui simule la session interactive composée des commandes : # passwd # cd /var/yp # make passwd c T.Besançon (v ) Administration UNIX ARS Partie / 789

329 16 Mécanisme d authentification réseau : NIS 16.6 Master server NIS, ypxfrd, rpc.yppasswdd, yppasswd Sur un client NIS Linux : % yppasswd Changing NIS account information for besancon on linux.unixiens.org. Please enter old password: ******** Changing NIS password for besancon on linux.unixiens.org. Please enter new password: ******** Please retype new password: ******** The NIS password has been changed on linux.unixiens.org. Sur un serveur maitre NIS Solaris : % yppasswd Enter login(nis) password: ******** New password: ******** Re-enter new password: ******** NIS passwd/attributes changed on linux.unixiens.org c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.7 Netgroups Chapitre 16 Mécanisme d authentification réseau : NIS 16.7 Netgroups «/etc/netgroups» Le système NIS permet de définir des groupes d autorisation d accès : les netgroups. Ces groupes sont diffusés via la map netgroup. Un netgroup est un nom symbolique associé à un ensemble de triplets (je n ai jamais vu le troisième champ avoir une quelconque utilité en pratique) : nom-de-netgroup \ (machine, utilisateur, nom-de-domaine-nis) \ (machine, utilisateur, nom-de-domaine-nis) \... On définit en pratique des netgroups concernant des machines et des netgroups concernant des utilisateurs. On autorisera ainsi ou pas des groupes d utilisateurs ou de machines à accéder à certaines ressources. c T.Besançon (v ) Administration UNIX ARS Partie / 789

330 16 Mécanisme d authentification réseau : NIS 16.7 Netgroups Exemple de netgroup de machines : nains \ (atchoum.example.com,,mine-de-diamants) \ (dormeur.example.com,,mine-de-diamants) \ (joyeux.example.com,,mine-de-diamants) \ (grincheux.example.com,,mine-de-diamants) \ (prof.example.com,,mine-de-diamants) \ (timide.example.com,,mine-de-diamants) \ (simplet.example.com,,mine-de-diamants) Exemple de netgroup d utilisateurs : etudiants \ (,jean,) \ (,pierre,) \ (,valerie,) c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.7 Netgroups Exemple d utilisation d un netgroup d utilisateurs au niveau de «/etc/passwd» : field:password HERE:0:1:Field Service:/usr/field:/bin/csh operator:password HERE:5:28:Operator:/opr:/opr/opser sys:password HERE:2:3:Mr Kernel:/usr/sys: bin:password HERE:3:4:Mr Binary:/bin: pot:*:16:16:menupot:/users/staffs/pot: -@etudiants: +@net_administrateurs::0:0::: +@net_utilisateurs::65534:65534:::/bin/noshell Signification : On rejette les lignes de la map «passwd» dont le login est indiqué dans le netgroup «etudiants» On accepte les lignes de la map «passwd» dont le login est indiqué dans le netgroup «net_administrateurs» On accepte les lignes de la map «passwd» dont le login est indiqué dans le netgroup «net_utilisateurs» c T.Besançon (v ) Administration UNIX ARS Partie / 789

331 16 Mécanisme d authentification réseau : NIS 16.7 Netgroups Exemple d utilisation d un netgroup de machines au niveau de l exportation de disques via NFS (fichier «/etc/exports, cf chapitre sur NFS) : /usr/openwin -access=nains c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS 16.8 Installation de NIS Chapitre 16 Mécanisme d authentification réseau : NIS 16.8 Installation de NIS Master server Lancer «ypinit -m» Slave servers Lancer «ypinit -s serveur-maitre» Ajouter dans la crontab les appels aux scripts «ypxfr_*» Client NIS Spécifier le domainname c T.Besançon (v ) Administration UNIX ARS Partie / 789

332 Chapitre 17 Mécanisme d authentification réseau : NIS+ c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS Introduction / Conclusion Chapitre 17 Mécanisme d authentification réseau : NIS Introduction / Conclusion Cf annexe pour un document sur NIS+. Nous n évoquerons ici que les défauts de NIS ayant conduit à l apparition de son successeur, NIS+. Le système NIS+ n a pas connu de succès et il est maintenant officiellement abandonné au profit de LDAP par son principal défenseur, SUN. c T.Besançon (v ) Administration UNIX ARS Partie / 789

333 17 Mécanisme d authentification réseau : NIS Introduction / Conclusion Principaux reproches à NIS : pas d authentification du client aux serveurs NIS ; connaitre le domainname suffit à se binder les maps sont transmises en totalité même en cas de faible modification de leurs contenus inadaption du principe du domaine NIS dans le cas de structures WAN mode broadcast c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : NIS Annexe 1 Chapitre 17 Mécanisme d authentification réseau : NIS Annexe 1 Ci joint dans la version imprimée de ce cours, un document sur NIS+. c T.Besançon (v ) Administration UNIX ARS Partie / 789

334 Solaris ONC Network Information Service Plus (NIS+) A White Paper

335 1991 by Sun Microsystems, Inc. Printed in USA Garcia Avenue, Mountain View, California All rights reserved. No part of this work covered by copyright may be reproduced in any form or by any means graphic, electronic or mechanical, including photocopying, recording, taping, or storage in an information retrieval system without prior written permission of the copyright owner. Portions of this paper were previously published in the proceedings of Sun User Group, United Kingdom (SUG UK), The OPEN LOOK and the Sun Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun s licensees. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS (October 1988) and FAR (June 1987). The product described in this manual may be protected by one or more U.S. patents, foreign patents, and/or pending applications. TRADEMARKS Sun Microsystems, the Sun Logo, NFS, NeWS and SunLink are registered trademarks, and Sun, SunSoft, the SunSoft Logo, Solaris, SunOS, AnswerBook, Catalyst, CDWare, Copilot, DeskSet, Link Manager, Online: DiskSuite, ONC, OpenWindows, SHIELD, SunView, ToolTalk and XView are trademarks of Sun Microsystems, Inc., licensed to SunSoft, Inc., a Sun Microsystems company. SPARC is a registered trademark of SPARC International, Inc. SPARCstation is a trademark of SPARC International, Inc., licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. UNIX and OPEN LOOK are registered trademarks of UNIX System Laboratories, Inc. X Window System is a product of the Massachusetts Institute of Technology. All other products referred to in this document are identified by the trademarks of the companies who market those products. ii SunSoft

336 Table of Contents Executive Summary 1 Introduction 1 NIS+ Overview 2 NIS+ Features 5 Who Benefits? 6 NIS+ Architecture 7 Implementation of NIS+ Service 15 Glossary of Terms 20 Network Information Service Plus (NIS+) iii

337 iv SunSoft

338 Network Information Service Plus (NIS+) Chuck McManis, Saqib Jang Executive Summary The enormous growth in network computing over the past few years presents significant challenges for distributed system administrators, end users, and application developers. Distributed networks have become larger, typically consisting of interconnected subnetworks spanning multiple sites. Management of these networks, with tasks such as addition, relocation, and removal of network resources, including hosts, applications, and printers, has taken on added complexity. The growth in size of distributed systems presents complex requirements for applications and end users to transparently access resources across a network. To a large extent, such challenges can be addressed through the deployment of a robust, high-performance, network-accessible repository of distributed system resources commonly called an enterprise naming service. This paper provides an architectural overview of SunSoft s Network Information Service Plus (NIS+), an enterprise naming service for heterogeneous distributed systems. Introduction NIS+ replaces ONC Network Information Service (NIS) and is designed to address the management and resource location requirements for heterogeneous distributed systems of the 90s. It is a repository of user-friendly names and attributes of network resources such as hosts, applications, users, and mailboxes. Clients of NIS+, both applications and users, can efficiently look up information on network resources and access these resources in a locationindependent way. NIS+ also plays a critical role in the efficient operation and administration of distributed systems by acting as a central point for addition, removal, or relocation of resources. 1

339 The NIS+ naming service was designed to address the following goals: To prevent unauthorized access to network resources and act as the platform for distributed system security. To scale effectively from very small to very large networks, consisting of tens of thousands of systems. To provide the ability to easily administer from very small to large networks, spanning multiple sites. To provide for autonomous administration of subnetworks. To provide highly consistent information. NIS+ Overview NIS+ works with the ONC distributed computing platform, which is an integral part of the Solaris environment. Solaris 2.0 is comprised of SunOS 5.0, enhanced ONC, NIS+, OpenWindows V3, DeskSet V3, and OPEN LOOK. A network computing standard that enables Solaris-based systems to connect to any other proprietary or standard system, ONC permits users to access information throughout the network and make use of all the computing power in the user organization, regardless of location. ONC is supported on all major hardware platforms, from PCs to mainframes. With an installed base of over 1.3 million systems, ONC is unrivalled as the industry standard for distributed computing in heterogeneous networks. NIS+ is a client/server application built atop the ONC Transport-Independent Remote Procedure Call (TI-RPC) interface. RPC applications are also clients of the NIS+ name service. Since the RPC client and server components of an application may be located on arbitrary machines in a large network, RPC clients use the name service to locate and bind to RPC servers in a flexible and high-performance way. NIS+ Enhancements NIS+ includes enhancements which fall into three general categories: the structure of the global namespace 1, the structure of data within maps, and the authentication and authorization models associated with the namespace and the data that it contains. 1. Refer to Glossary of Terms at the end of this paper for definition of namespace and other terms. 2 SunSoft

340 First, NIS+ includes support for hierarchical domain names, which is a better model for a namespace of many smaller domains. This model has been very successfully used by the Domain Name System that is currently deployed on the Internet and brings other benefits to the system as well. The most important benefit is that hierarchical domains provide a structure upon which to hang a distributed authority mechanism. Other advantages of hierarchical names are that given some basic information, there are well-known mechanisms for locating nodes within a tree, and a mechanism for generating globally unique names that can be based on using the domain name as part of the name. Secondly, NIS+ includes a new database model, which consists of two parts. The first part is a record containing the schema for the database that is stored in the namespace. The second part is the database itself, which is managed by the same server that serves the portion of the namespace where the schema record was found. To keep the databases simple and the representation of the schema manageable, only two properties of the database were chosen to be part of the schema. These properties are the number of columns in a database, and an indication for each column as to whether or not it should be used as one of the indexes for the database records. Additionally, for columns that were determined to be searchable, a flag is present to specify whether or not the case of the characters should be considered when searching the database with this index. Using this model, NIS dbm databases are described as twocolumn databases, with the first column searchable and case sensitive. Figure 1 shows a graphical representation of how these hierarchical domains and databases, called tables, are related in a global namespace. Network Information Service Plus (NIS+) 3

341 Replica Server Master Server Replica Server Number of Columns : n Searchable Column : 0,1 Case Sensitive Columns : 0 Col 0 Col 1 Col 2... Col n Replica Server Table Table Figure 1 Graphical Representation of the New NIS+ Namespace Thirdly, there are two classes of changes that have been made to the NIS authentication and authorization model. One is the ability to authenticate access to the service and thus discriminate between accesses that are allowed to members of the community versus other network entities. The other is an authorization model to allow specific rights to be granted or denied based on this authentication. Authentication is provided by mechanisms available to all users of ONC RPC. This allows the server to ensure the identity of principals making requests and clients to ensure the identity of the server answering the request. A second change is the need for the information to have an authorization model associated with it. This is accomplished by using an authorization model similar to the UNIX file system model. This model specifies that each item in the namespace has a set of access rights associated with it, and that these rights are granted to three broad classes of principals: the owner of the item, a group owner of the item, and all other principals. The specific access rights are different than the traditional read, write, and execute rights that the file system grants owing to the nature of information 4 SunSoft

342 services. Also, it is useful to include a class of clients which are not authenticated, the nobody principal. The authentication and authorization mechanisms incur a finite performance penalty when they are in effect. By allowing the client to specify access rights to unauthenticated principals, we allow them to choose better performance at the cost of weaker security. Finally, access rights to individual rows and columns within the database are also provided. This provides a desirable property, that we can maintain the privacy of particular fields in a record, such as the encrypted password, while still giving unrestricted access to the other fields of database records. NIS+ Features The highlights of the NIS+ naming service s capabilities are: Support of hierarchical namespace enables simplified distributed management. The namespace can be divided into domains with each domain managed on an autonomous basis. Comprehensive and flexible security mechanisms prevent unauthorized access to network resources. Authentication facilities allow verification of a client s identity, while authorization is provided to ensure the client has rights to perform desired name service operation. Partitioning of name service information provides improved scalability. The unit of partitioning is the directory which contains object information for each namespace domain. Replication, on a per-directory basis, allows high availability/reliability. Each domain has a master directory to which all updates are applied and a number of slave replicated directories. Fast consistency between directory replicas enables support of rapidly changing network environments. Complete and consistent suite of administrative, namespace and information base functions with programmatic interfaces enables simplified access to and management of (subject to security constraints) name service. Administrative operations can be performed remotely and flexibly. Namespace and information base operations allow applications and users to efficiently access and modify information on network objects. Compatibility to allow NIS-based applications and environments to migrate smoothly to NIS+. Network Information Service Plus (NIS+) 5

343 Who Benefits? System Administrators NIS+ is a powerful tool for simplified administration of heterogeneous distributed systems. As the size of such systems grows and the requirements for decentralized administration emerge, a multidomain hierarchical namespace can be created. Assignment of names and modification of information on network resources within each domain can be decentralized. Further, the hierarchy can correspond to organizational (with each domain representing a functional group, for example, Engineering or Marketing) or logical hierarchies, allowing administrators to use intuitive schemes for organizing their namespace. Comprehensive security schemes benefit administrators by ensuring that the name service is protected from unauthorized access. This is critical since the name service functions as the primary means for administrators to add, remove, or modify network resources. The security functionality is flexible as administrative groups can ensure that name service information under their control is protected from access and modification by principals outside of that organization. Partitioning allows administrators to continue using NIS+ as the platform for distributed management as networks grow in size. As multiple domains are created, the overall namespace can have unbounded growth, yet the size of an individual directory remains within bounds. Replication of individual directories, on a master/slave basis, allows coping with computer and communication link failures. In addition, NIS+ provides for fast transfer of updates from master to slave servers, allowing authorized administrators to rapidly add, remove, or relocate network resources. NIS+ also includes a set of functions for flexible and easy administration of the name service itself. This includes functions for starting and stopping NIS+ servers, replicating and partitioning operations, and setting security levels. NIS+ functions support a corresponding Application Programming Interface (API) designed to allow NIS+ to be the platform for next-generation administrative applications from SunSoft and Independent Software Vendors (ISVs). 6 SunSoft

344 Application Developers Application developers can use the NIS+ API in a number of ways. First, applications can use the API to lookup information on network resources. The SunOS 5.0 system uses NIS+ as the repository for storage of information on hosts, passwords, and users for administrative purposes. Applications can use the NIS+ API to access this information in a high-performance fashion. Second, NIS+ can be used as a secure repository of network-accessible applicationspecific data. Improved consistency and the read/write capability within NIS+ API enable the service to be used to store and modify application-specific information. For example, the OpenWindows V3 Calendar Manager uses NIS+ to store group schedule information that authorized group members can access and modify to schedule meetings. Finally, new administrative applications can be developed that run atop the API and take advantage of its simplicity and consistency in providing access to network resources. NIS+ will serve as the platform for future administrative applications from SunSoft. NIS+ also provides full compatibility with the NIS (i.e., yp_xxx) programming interface to allow ease of application migration. End Users NIS+ Architecture NIS+ also provides significant advantages for end users. The security functionality within NIS+ enables users to trust network communications and to protect sensitive information from unauthorized access. Users productivity increases as applications transparently locate resources by accessing the central data storage facility with NIS+. The simplicity and completeness of the NIS+ interface enables users to take on a greater proportion of administrative tasks, which is particularly advantageous where administration resources can t keep pace with constantly growing distributed systems. NIS+ provides two types of services to clients. The first is a name service that maps names, such as domain names, to their respective servers. The second is a directory service where the desired information itself is returned, rather than a pointer to it, such as the UNIX password record. Network Information Service Plus (NIS+) 7

345 NIS+ Naming Model The naming model used by NIS+ is a graph structured as a singly rooted tree. Within this graph each vertex represents one NIS+ object, each of which may have several children associated with it but only one parent. There are six types of NIS+ objects defined: directory, table, group, link, entry, and private. Directory objects identify a database of NIS+ objects. Objects within that database are represented as children of the directory object. A directory object and all of its children is an NIS+ domain. An NIS+ directory that is a child of another NIS+ directory is a subdomain, and all domains below the root directory are the NIS+ namespace. An NIS+ object name consists of several labels, each separated from the next by a dot (. ) character. The rightmost label is closest to the root of the namespace. Labels that contain the dot character are quoted. These names are shown graphically in Figure 2. Names that end with the dot character are said to be fully qualified, whereas names which do not are said to be partially qualified. Names that identify objects in the namespace are called NIS+ regular names. mumble baz fred foo bar bob.smith bob.smith.fred.mumble. foo.bar.baz.mumble. Figure 2 Construction of a Multipart NIS+ Name 8 SunSoft

346 NIS+ Database Model Table objects in the NIS+ namespace identify databases called tables. These databases are called tables because the model used is that of a columnar table. The object contains the schema for the database it identifies. This schema specifies the number of columns in the table and identifies which columns can be searched with an NIS+ query. Rows within an NIS+ table are identified by a compound name syntax called indexed names. These names contain a search criterion and a regular name. The regular name portion identifies the NIS+ table to search. The search criterion identifies the rows of interest by specifying what value one or more searchable columns must contain to satisfy the search. The search criterion consists of an open bracket [ followed by zero or more attributes of the form column_name = column_value followed by a close bracket character ]. Attributes in the search criterion are separated by commas, and the search criterion and the name of the table to apply it to are also separated by commas. An example of these compound names is shown in Figure 3. In the first example, the name [manager=susan],employees.widget.com. selects only the fourth row which satisfies this search. In the second example, the name [manager=george],employees.widget.com. selects the first three rows which all satisfy the search criterion. Finally the name [manager=george, name=bob],employees.widget.com. would return only the first row, because only that row satisfies the complete criterion. The null search criterion, [ ], selects all of the rows. Table name: employees.widget.com { name manager department division } bob george engineering electronics mary george engineering electronics jane george engineering electronics sam susan sales electronics [manager=susan], employees.widget.com. [manager=george],employees.widget.com Figure 3 Indexed Names Selecting Entries From a Table Network Information Service Plus (NIS+) 9

347 The set of names that NIS+ will accept can be defined by the grammar shown in Figure 4. This grammar defines the terminal characters dot (.), comma (,), open bracket ([), close bracket (]), and equals (=). Generally, it is inadvisable to put terminal characters in the strings that make up the NIS+ names. However, should that be necessary, a quoting mechanism based on the double quote ( ) character is provided. All characters between two double quote characters are not scanned. The double quote may itself be quoted by placing two double quote characters adjacent to each other. These two characters are treated as a single instance of the double quote character. NAME REGULAR_NAME INDEXED_NAME ::= <REGULAR NAME> <INDEXED_NAME> ::=. <STRING>. <STRING>. <REGULAR_NAME> ::= <SEARCH_CRITERION>, <REGULAR_NAME> SEARCH_CRITERION ::= [ <ATTRIBUTE-LIST> ] ATTRIBUTE_LIST ATTRIBUTE STRING ::= <ATTRIBUTE> <ATTRIBUTE>, <ATTRIBUTE -LIST> ::= <STRING> = <STRING> ::= see note Note: ISO Latin 1 character set, the initial character in the string may not be or - ; embedded terminal characters must be protected by double quotes. Figure 4 NIS+ Name Grammar In addition to the schema, the table object holds other properties associated with the database. These include the tables type, a concatenation path, and a separator character that clients printing entries from the table use to separate the data from each column in the output. All of these properties are shown graphically in Figure SunSoft

348 Table: foe.bar. Type: foo records Path:foo.bar. :fie.bar. Table: fie.bar. Type: Entry foo records Column Path:foo.bar. Column :foe.bar.... Data 1 2 Table: foo.bar. Entry Row 0 Column Column Column Type: Data foo records 1 Path:fie.bar :foe.bar. n Row 1 Entry Row 0 Column Column Column Data Row n Row 0... Row m Row 1 Row m... Row m Column n Search Path Starting from foo.bar Figure 5 Graphical Representation of an NIS+ Table The type property is a string that the server uses to prevent adding to a table entries that are not compatible with the other entries in the table. This string is compared to the type string of the entry being added and, if they do not match, the update is rejected. The server also compares the number of columns in the entry being added to the number of columns in the table, as well as their type (binary or text) to minimize mistakes that could corrupt the database. The concatenation path, or search path, is a string containing the list of tables to search if the search criterion in the indexed name doesn t match any entries in the table. This search path allows all of the tables identified within it to appear to the client as one large table. When entries from several tables in the path all match the same search criteria, the first ones found are the ones returned to the client. In addition to the column data, each row in a table contains some specific information about itself in the column labelled Entry Data. This entry data consists of the name of the owner for this row, a group owner, a time-to-live value for the row, and a set of access rights for this row. The entry data is Network Information Service Plus (NIS+) 11

349 combined with the data from the columns when a row is returned in the form of an entry object. This data is present for all rows, but is neither searchable nor explicitly identified as a column in the table object. NIS+ Object Model NIS+ objects are implemented as variant records. All objects share a common set of properties which include an owner name, group owner name, access rights, object identifier, and time-to-live values. Additionally, each type of object has a variant part that contains specific information for that type of object. Directory objects contain the names, addresses, and authentication information for machines that serve a domain. Table objects contain the schema for NIS+ tables. Group objects contain a list of principals that are members of that group. Link objects contain the name of another object, and entry objects contain data from an NIS+ table. A diagram of these objects is shown in Figure 6. The shaded portion represents properties that are unique to a particular type of object. The top portion show properties that are common to all objects. DIRECTORY TABLE GROUP LINK ENTRY iod name domain owner group access rights time to live directory name table type group flags link name entry s type directory type number of columns group members(s) link type entry data servers(s) column description(s) member 0 datum 0 master column 0 member 0 datum 1 replica(s) column Common Properties Variant Properties Figure 6 Format of NIS+ Objects 12 SunSoft

350 NIS+ Authorization Model The NIS+ authorization model has four different access rights that can be granted to four classes of NIS+ principal. The four classes of principal are: the owner of an object; the group owner, which is a set of principals that is specified by a group object; the set of authenticated principals that are known to the NIS service, called collectively the world; and the set of unauthenticated principals called collectively the nobody principal. The four access rights that are grantable are read, modify, create, and destroy. Read conveys the right to read the contents of objects, directory objects, and table objects. Modify conveys the right to change the attributes of an object such as the owner, group owner, time-to-live, and so forth. For directory and table objects, create conveys the right to add objects to the namespace controlled by that object, either a domain or a database, depending on the object s type. Destroy conveys the right to remove objects from directories or tables. Domains and tables have additional access rights masks that allow rights to be granted with a finer degree of granularity. The NIS+ service uses authentication information extracted from the RPC messages it receives to identify the NIS+ principal making the request. ONC/RPC messages have attached to them authentication information in the form of an authentication flavor. Each flavor of authentication contains a unique principal name. The service uses this name and the authentication type to search an NIS+ table named cred.org_dir.<domain>. In that table, there is an entry that contains the flavor-specific name and the NIS+ principal name. This NIS+ defined name is used in the authorization mechanism rather than the authentication flavor-specific name. This mapping allows the NIS+ service to accept different flavors of authentication information and continue to work correctly. The authorization model for tables is somewhat more sophisticated than that of the namespace. Access rights in tables can be granted on a per table, per entry, and per column basis. Each level supersedes all subsequent levels. Thus, if read access is allowed for the table, it is allowed for every row and every column in the table. If read access is not allowed for the table but is allowed for a particular row, then it is allowed for all columns in that row. Finally, if read access is not allowed for the table and not allowed for the row but is granted for a particular column, then that column s value is returned. This is shown graphically in Figure 7. Each mask serves to narrow the authorization to a finer grain. In the figure, the entire table is readable only by the owner of the table. Network Information Service Plus (NIS+) 13

351 However, all of Row 1 is readable by the group owner of that row. Finally, Column 1 of Row 1 is readable by all NIS+ principals. The modify right may be similarly granted. Table: foo.bar. Type: foo records Path:fie.bar. :foe.bar. Row 0 Row 1... Row m Entry Data Column 1 Column 2... Column n Table Object access rights: r----/----/---/---- Access rights shown for: owner/group/world/nobody Row m Entry data: -----/----/r--/---- Column n access rights: -----/----/r--/---- DATUM Figure 7 Access Rights for Tables Showing Narrowing of Access Rights The service enforces read access by censoring the information that the requesting principal is not allowed to read. When one or more, but not all, columns of an entry are protected, the protected columns have the sensitive data replaced by the *NP* string. Entries that are completely protected are simply removed from the list of entries that are returned. If no access to the table is allowed, an error of NIS_PERMISSION is returned. 14 SunSoft

352 NIS+ Replication Model Implementation of NIS+ Service Like the existing NIS service, NIS+ domains are replicated using a master and slave model. However, the replication is done on a per domain basis with each internal node in the hierarchy having its own master and replicas. Further, all changes to either a domain or a table within that domain are logged on an event basis, and it is these change events that are propagated to replicas rather than to complete databases. The components of the NIS+ design which implement these models are shown in Figure 8. The highlighted components are currently part of the SunOS system and are not considered to be part of this design. In Figure 8, each box represents a set of interfaces. Dependencies are not strictly linear since the location mechanism may be required to lookup directory objects within the NIS+ namespace, and this causes it to make use of the NIS+ client library interfaces. Application / System API NIS+ Client Library RPC Authentication Mechanism NIS+ Location Mechanism Cache Manager ONC/RPC NIS+ Service Daemon Database Storage/Retrieval Mechanism Figure 8 The Components of the NIS+ Service Network Information Service Plus (NIS+) 15

353 NIS+ Client Library The NIS+ client library interface provides the application interface to the NIS+ service. Generally, applications have their own naming interface that meets their particular requirements. For example the operating system defines a naming interface gethostbyname( ), which takes a host name and returns a structure containing addressing information about that machine. This additional level of indirection allows different naming services to be used in different implementations of the interface. The NIS+ client library is designed to provide a set of capabilities upon which custom naming interfaces may be built. The two primary operations that are provided are the lookup and list operations. The lookup operation locates objects in the namespace and the list operation searches tables. Both provide the service binding and name resolution functions. Additionally, they provide services specific to their operation. The lookup routine implements the symbolic link facility. When a lookup request is made and the object returned is a link, the function checks to see if a flag was passed that specified links were to be followed. If it was, the function restarts the lookup using the name stored within the link. Similarly, the list function implements the table search paths. When a search of an NIS+ table returns no entries, and the user has specified that the table s path is to be followed, this function begins searching each table in the path until a match is found or the path is exhausted. The client library also provides the service location mechanism. All NIS+ clients have a file in their file system that contains the name, address, and authentication information for at least one trusted machine. Requests for service go to that machine or machines first when the client boots up. When the desired name is not within the local domain, the machine serving the domain is queried for a server that does serve the desired domain. This query will be answered by either the name of a server who serves that domain or a server that is closer to that domain. The location function will cache this information with a local daemon named the NIS+ cache manager. If the returned information is not the desired domain, the domain returned is queried for the name of a machine serving the desired domain. In this way, all nodes in the namespace can be located. 16 SunSoft

354 The client library also provides the interfaces to add, remove, or modify NIS+ objects and entries in NIS+ tables. Various routines for manipulating NIS+ names, routines for returning the NIS+ names associated with the current process, and various object handling functions, round out the package. NIS+ Cache Manager The NIS+ location mechanism is predicated on the fact that a machine that serves a domain is itself a client of a domain above the one it serves. When a location request comes from a client for a domain, the service checks to see if it serves the requested domain. If it does not serve the domain, then it checks to see if the desired domain is below the domain it serves in the namespace. If the desired domain is below its domain, it locates the directory object in its domain that is an ancestor of the desired domain and returns that to the client. If the desired domain is located above the server s domain, it returns the directory object for its domain, which is always above the one it serves. Eventually this mechanism will find its way to the root of the namespace and begin to work its way down again. Once the desired directory object is found, the service returns it to the client. Prior to returning the directory object, it signs it with a cryptographic checksum, using a key that only a root process on the client machine will know. When the client library gets the directory object, it passes it to the cache manager which verifies the signature and adds it to its shared memory cache of directories. Future client requests will find the directory object in the cache manager s cache and avoid the time-consuming location step. NIS+ Service Daemon Once the directory object for a domain is located, the client library will attempt to bind to each of the servers within it until a binding is successful. Update operations will attempt to bind only to the master server. Given a binding, the client library then makes an RPC call to the NIS+ service. The service uses a virtual memory database to store its information. It receives the request, checks the access rights, and then responds with the requested information. The database used is linked to the service at runtime using the shared library facilities of the SunOS system. The use of shared libraries allows the database to be replaced with specialized versions for different applications. Network Information Service Plus (NIS+) 17

355 An In-depth Look at an NIS+ Operation A diagram showing the execution of an NIS+ lookup is provided in Figure 9. An NIS+ operation begins with a call to an application or system library interface (1) that uses NIS+ in its implementation. Most often, this operation will be a search of an NIS+ table. In our example, the gethostbyname function call searches the hosts table. The gethostbyname function then calls the NIS+ client library in Step 2. The client library looks in the cache manager s shared memory location cache for the name and address of an appropriate machine. If there are no appropriate bindings, the client library will locate one using Steps 2.1 and 2.2 to call the nis_finddirectory function in search of a server. When a machine is located, the client library issues an RPC request, Step 3, to talk to the service. The service consults its database and returns the results in Step 4. The client library takes the results and passes them up to the application interface in Step 5, and the gethostbyname call converts the data in the entry object into a struct hostent for the calling program. 18 SunSoft

356 hostent *gethostbyname( pepper ); 6 1 Local library API Cache Manager Legend: Shared Memory Interface Shared Library Interface Remote Procedure Call Cache Message Protocol Shared Memory Mapping NIS+ Client Library 3 Cache Library 2.2 NIS+ find_directory() NIS+ Service Daemon Structured Storage Manager NIS+ Service Daemon Structured Storage Manager Occurs on Cache Miss Figure 9 Execution of an NIS+ Lookup Network Information Service Plus (NIS+) 19

357 Glossary of Terms Throughout this document, terms are used that have specific meanings. These terms are collected here for easy reference. API Binding Credential Datum dbm DNS Domain Global Namespace Information Base The Application Programming Interface, or API, consists of a series of C routines that give application programs access to the naming service. An NIS+ name, protocol information and valid credential for the local NIS+ server. This information is sufficient to contact the server and resolve names administered by it. A piece of information that identifies the user or host providing it. If the information is encrypted in such a way that only its true owner, as opposed to an imposter, could encrypt it, then it is a Secure Credential. The dbm structure that NIS uses: it consists of an opaque key and an opaque data array. A collection of C language routines that implement a very simple database. The database is divided into maps. The Domain Name Service: the Internet name service that is defined in RFC 1034 and RFC A namespace administered by a single authority. The domain contains one or more servers that have its directory. The space of all possible names that NIS+ can name. This space starts at dot (.) and goes down. A generic term for a collection of information that is named. 20 SunSoft

358 Internet Leaf Node Namespace Object Object Value Principal A network whose participants are machines and users from more than one organization. Additionally, those organizations do not share any common management at any level. A leaf node or name has no other names below it in the namespace tree. A namespace is a collection of names administered by a single authority. This space can be composed of several branches of the Organizational Namespace. An NIS+ object is the basic unit in the namespace. This data structure consists of an administrative part that identifies ownership, access rights, and so forth, and a data part that contains the value of the object. The data portion of an NIS+ object. Clients of the naming service, such as users and hosts, having credentials. Network Information Service Plus (NIS+) 21

359 22 SunSoft

360 SunSoft, Inc Garcia Avenue Mountain View, CA For more information, call Printed in USA 9/ K

361 Chapitre 18 Mécanisme d authentification réseau : LDAP c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.1 Problématique Chapitre 18 Mécanisme d authentification réseau : LDAP 18.1 Problématique Cas de l université de Paris 4 : base Microsoft Excel du personnel administratif base Microsoft Access du personnel enseignant base «/etc/passwd» des comptes des utilisateurs base mysql des 2 catégories de personnel prochainement logiciel à base d Oracle prochainement Microsoft Active Directory Question 1 : envoyer un à tous les personnels administratifs sachant que le service du personnel ne fournira qu une liste avec nom et prénom. Comment l ingénieur système fait-il? Question 2 : envoyer un à tous les personnels administratifs sauf ceux du site de Clignancourt, sachant que le service du personnel ne peut pas fournir de liste cette fois-ci. Comment l ingénieur système fait-il? c T.Besançon (v ) Administration UNIX ARS Partie / 789

362 18 Mécanisme d authentification réseau : LDAP 18.2 Principe d annuaire Chapitre 18 Mécanisme d authentification réseau : LDAP 18.2 Principe d annuaire Un annuaire informatique est un service permettant d accéder à des informations, relatives à des personnes ou à diverses ressources de façon organisée. Objectif : maintenir de façon cohérente et contrôlée les archipels de données et obtenir des données de référence. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.2 Principe d annuaire Un annuaire n est pas une base de données relationnelles. Une base de données (SGBD) se caractérise par : Le schéma des données est défini à 100% pour résoudre un certain problème. Les applications connaissent explicitement le schéma des données. Les objets sont complexes et éclatés entre plusieurs tables liées par des relations complexes. Un SGBD supporte les transactions. Un SGBD supporte un langage comme SQL qui permet des fonctions d interrogation et de mises à jour très complexes. Un SGBD centralise les données pour éviter les problèmes de synchronisation de données et de qualité des temps de réponse. c T.Besançon (v ) Administration UNIX ARS Partie / 789

363 18 Mécanisme d authentification réseau : LDAP 18.2 Principe d annuaire Un annuaire se caractérise par : Les objets sont indépendants (pas de liens de dépendance entre eux). Les objets peuvent être distribué sur plusieurs annuaires pour assurer une meilleure disponibilité. Le schéma est standardisé pour pouvoir partager les données. Le schéma est extensible pour prendre en compte tous les besoins mais cela est fait de façon compatible avec les standards. Les applications d annuaire ignorent la structure interne des données. Un annuaire est principalement consulté en lecture et est optimisé pour cela. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.3 Annuaire LDAP Chapitre 18 Mécanisme d authentification réseau : LDAP 18.3 Annuaire LDAP LDAP Lightweight Directory Access Protocol Héritier de l annuaire ISO X500. Version 3 actuellement. RFC 2251 à 2256, RFC 2829 à 2830, RFC Il n y a pas de standard de représentation des contrôles d accès aux données. LDAP : nom d un protocole nom d une structure de données nom d implémentations de serveurs suivant le protocole Confusion possible... c T.Besançon (v ) Administration UNIX ARS Partie / 789

364 18 Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe Chapitre 18 Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe Les entrées sont organisées sous forme d arbre ou DIT (Directory Information Tree). L une des difficultés de LDAP : construire l organisation du DIT. De quoi est-il le reflet? : DIT à caractère organisationnel? DIT à caractère géographique? Pas de solution universelle. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe DIT à caractère organisationnel? dc=company,dc=com dc=recherche dc=finance dc=marketing dc=people dc=people dc=people dc=groups dc=groups dc=groups c T.Besançon (v ) Administration UNIX ARS Partie / 789

365 18 Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe DIT à caractère géographique? dc=company,dc=com dc=america dc=europe dc=asia dc=people dc=people dc=people dc=groups dc=groups dc=groups c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe La racine de l arbre est uniquement conceptuelle et n existe pas réellement. C est le suffixe qui sert à déterminer les adresses absolues des objets (comme «/» pour l arborescence des fichiers UNIX). dc=company,dc=com SUFFIXE dc=recherche dc=finance dc=marketing dc=people dc=people dc=people dc=groups dc=groups dc=groups c T.Besançon (v ) Administration UNIX ARS Partie / 789

366 18 Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe Le suffixe peut avoir plusieurs formes : forme 1 : «o=company.com» forme 2 : «o=company,c=com» forme 3 : «dc=company,dc=com» On préférera la 3ième forme. Explication : donnée dans RFC On sait que les noms de domaine sont garantis uniques. Comme les annuaires peuvent être répartis, avec ce principe d unicité des noms de domaine DNS, on garantit l unicité des contextes de nommage LDAP. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.4 Modèle de données de LDAP : DIT, suffixe Exemple de DIT visualisé avec LdapBrowser disponible à l URL : c T.Besançon (v ) Administration UNIX ARS Partie / 789

367 18 Mécanisme d authentification réseau : LDAP 18.5 Modèle de données de : entrée, attributs, DN, URL Chapitre 18 Mécanisme d authentification réseau : LDAP 18.5 Modèle de données de LDAP : entrée, attributs, DN, URL DSE Directory Service Entry Les entrées dans le DIT (DSE) sont des agrégats d attributs monovalués ou multivalués qui permettent de stocker n importe quel format de données (prénom, numéro de téléphone, image, son, etc.) Les DSE sont stockées dans le DIT et arrangés selon leur identifiant unique, le DN (Distinguished Name). Un DN est la concaténation d un RDN (Relative DN) et du DN des parents. Un DN s apparente à une clef primaire. suffixe : dc=company,dc=com RDN : ou=recherche DN : ou=recherche,dc=company,dc=com RDN : uid=besancon DN : uid=besancon,ou=recherche,dc=company,dc=com (le RDN doit être un des attributs/valeurs du DSE) c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.5 Modèle de données de LDAP : entrée, attributs, DN, URL c T.Besançon (v ) Administration UNIX ARS Partie / 789

368 18 Mécanisme d authentification réseau : LDAP 18.5 Modèle de données de LDAP : entrée, attributs, DN, URL Il existe des URL LDAP (RC 2255) qui prennent la forme : ldap://serveur:389/dn Par exemple dans communicator de netscape : c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Chapitre 18 Mécanisme d authentification réseau : LDAP 18.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Le schéma du DIT regroupe les définitions relatives aux types d objets que peut contenir l annuaire ou que l on peut rechercher. Le schéma contiendra des objets instanciations de classes LDAP, les définitions de ces classes et de leurs attributs, les syntaxes de ces attributs. Tous ces éléments seront identifiés par des Object Identifiers dits OID. attributetype ( NAME uidnumber DESC An integer uniquely identifying a user in a domain EQUALITY integermatch SYNTAX SINGLE-VALUE ) objectclass ( NAME posixaccount SUP top AUXILIARY DESC Abstraction of an account with POSIX attributes MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) ( et sont des OIDS) c T.Besançon (v ) Administration UNIX ARS Partie / 789

369 18 Mécanisme d authentification réseau : LDAP 18.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Une syntaxe est un modèle de représentation des valeurs de l attribut. Par exemple booléen, entier, binaire (pour une image, un son), etc. L attribut objectclass spécifie la liste des classes qu instancie un DSE. Chaque classe va construire la structure du DSE en spécifiant une liste d attributs obligatoirement présents («MUST» dans l objectclass) et une liste d attributs facultatifs («MAY» dans l objectclass). c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Exemple : objectclass ( NAME inetorgperson DESC RFC2798: Internet Organizational Person SUP organizationalperson STRUCTURAL MAY ( audio $ businesscategory $ carlicense $ departmentnumber $ displayname $ employeenumber $ employeetype $ givenname $ homephone $ homepostaladdress $ initials $ jpegphoto $ labeleduri $ mail $ manager $ mobile $ o $ pager $ photo $ roomnumber $ secretary $ uid $ usercertificate $ x500uniqueidentifier $ preferredlanguage $ usersmimecertificate $ userpkcs12 ) ) objectclass ( NAME posixaccount SUP top AUXILIARY DESC Abstraction of an account with POSIX attributes MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) l attribut «uid» sera de type MUST. c T.Besançon (v ) Administration UNIX ARS Partie / 789

370 18 Mécanisme d authentification réseau : LDAP 18.6 Modèle de données de LDAP : schéma, syntaxes, OID, objectclass Les objectclass de LDAP s inscrivent dans un hiérarchie dont la racine est l objectclass «top». Chaque classe hérite d une seule classe mère. Chaque classe peut donner lieu à plusieurs sous classes. (Abstract) top (Structural) person (Auxiliary) companyperson (Structural) organizationalperson (Structural) residentialperson c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.7 Protocole LDAP / Bind Chapitre 18 Mécanisme d authentification réseau : LDAP 18.7 Protocole LDAP / Bind Au niveau réseau : LDAP : TCP port 389 LDAP + SSL : TCP port 636 ( syntaxe LDAP au format ASN.1 ) + BER Un dialogue LDAP s établit après une phase d ouverture de session dite bind. Le bind peut être anonyme ou authentifié. c T.Besançon (v ) Administration UNIX ARS Partie / 789

371 18 Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF Chapitre 18 Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF Problème : comment manipuler les objets LDAP en pratique? Réponse : en les manipulant au format LDAP Data Interexchange Format, dit LDIF LDIF n intervient pas dans le protocole LDAP (pas de mention dans les RFC par exemple). LDIF n est compris que par les utilitaires qui le convertissent en protocole LDAP. c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF Attention aux caractères non ASCII : si la valeur d un attribut est uniquement composé de caractères ASCII, on l écrit «attribut : valeur» si la valeur d un attribut contient des caractères non ASCII, il faut coder cette valeur en UTF-8 puis la coder en BASE64 et écrire au final «attribut :: valeur2» Par exemple l attribut «description» de valeur Université de Paris-Sorbonne, Paris 4 ne sera pas codé en LDIF sous la forme description: Université de Paris-Sorbonne, Paris 4 mais sous la forme description:: VW5pdmVyc2l0w6kgZGUgUGFyaXMtU29yYm9ubmUsIFBhcmlzIDQ=! Notez les différences! c T.Besançon (v ) Administration UNIX ARS Partie / 789

372 18 Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF 2 utilitaires pratiques : A verifier... c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF Exemple d une DSE avec des caractères accentués non encore codés en LDIF : dn: ou=personnel,dc=paris4,dc=sorbonne,dc=fr objectclass: top objectclass: organizationalunit ou: Personnels de l Université de Paris-Sorbonne, Paris 4 businesscategory: academic research telephonenumber: +33 (0) facsimiletelephonenumber: +33 (0) postofficebox: Université de Paris-Sorbonne, Paris 4 postalcode: F postaladdress: 1 rue Victor Cousin l: Paris, France description: Université de Paris-Sorbonne, Paris 4 c T.Besançon (v ) Administration UNIX ARS Partie / 789

373 18 Mécanisme d authentification réseau : LDAP 18.8 Format de données LDIF Exemple d une DSE au format LDIF : dn: ou=personnel,dc=paris4,dc=sorbonne,dc=fr objectclass: top objectclass: organizationalunit ou:: UGVyc29ubmVscyBkZSBsJ1VuaXZlcnNpdMOpIGRlIFBhcmlzLVNvcmJvbm5lLCBQYXJpcyA0 businesscategory: academic research telephonenumber: +33 (0) facsimiletelephonenumber: +33 (0) postofficebox:: VW5pdmVyc2l0w6kgZGUgUGFyaXMtU29yYm9ubmUsIFBhcmlzIDQ= postalcode: F postaladdress: 1 rue Victor Cousin l: Paris, France description:: VW5pdmVyc2l0w6kgZGUgUGFyaXMtU29yYm9ubmUsIFBhcmlzIDQ= c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP 18.9 Implémentations Chapitre 18 Mécanisme d authentification réseau : LDAP 18.9 Implémentations Il existe plusieurs implémentations de LDAP : OpenLdap, version (au 21 août 2002) SUN ONE (anciennement Netscape Directory Server, racheté par SUN devenu Sun Iplanet Directory puis SUN ONE) incorporé de base dans Solaris 8 et ultérieur Novell Directory Services, version 4? autes annuaires commerciaux... Les différentes implémentations respectent les normes du protocole. Par contre, elles différent au niveau de tout ce qui n est pas norme. En particulier, les droits d accès aux données sont codés de façon incompatible. c T.Besançon (v ) Administration UNIX ARS Partie / 789

374 18 Mécanisme d authentification réseau : LDAP OpenLDAP Chapitre 18 Mécanisme d authentification réseau : LDAP OpenLDAP Cf Les versions 2.x.y d OpenLDAP sont compatibles avec les normes de LDAP v3. Le logiciel se compose de : du serveur LDAP «slapd» du serveur de synchronisation «slurpd» d utilitaires («slapadd», «ldapsearch», «ldapadd», «ldapdelete», «ldapmodify», «ldappasswd», etc.) librairies, include LDAP un fichier de configuration «slapd.conf» dans lequel on définit le suffixe, le rootdn, le mot de passe du rootdn c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP OpenLDAP Le mécanisme de réplication de serveurs OpenLDAP est le suivant : 1) demande de modification 2) réponse : referral slapd (Esclave) 7) slurpd client 6) 3) demande de modification 4) réponse (OK/not OK) slapd (Maitre) 5) Journal des modifications c T.Besançon (v ) Administration UNIX ARS Partie / 789

375 18 Mécanisme d authentification réseau : LDAP ObjectClass posixaccount, shadowaccount Chapitre 18 Mécanisme d authentification réseau : LDAP ObjectClass posixaccount, shadowaccount Cf RFC2307 Cf le schéma «nis.schema» dans OpenLDAP. L objectclass «posixaccount» est l objet qui implémente l équivalent de la structure C de «<pwd.h>» : objectclass ( NAME posixaccount SUP top AUXILIARY DESC Abstraction of an account with POSIX attributes MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) L objectclass «shadowaccount» est l objet qui implémente le principe des shadow passwds : objectclass ( NAME shadowaccount SUP top AUXILIARY DESC Additional attributes for shadow passwords MUST uid MAY ( userpassword $ shadowlastchange $ shadowmin $ shadowmax $ shadowwarning $ shadowinactive $ shadowexpire $ shadowflag $ description ) ) c T.Besançon (v ) Administration UNIX ARS Partie / Mécanisme d authentification réseau : LDAP Un peu de bibliographie Chapitre 18 Mécanisme d authentification réseau : LDAP Un peu de bibliographie c T.Besançon (v ) Administration UNIX ARS Partie / 789

376 Chapitre 19 Sélection de naming services, /etc/nsswitch.conf c T.Besançon (v ) Administration UNIX ARS Partie / Sélection de naming services, /etc/nsswitch.conf 19.1 Problématique Chapitre 19 Sélection de naming services, /etc/nsswitch.conf 19.1 Problématique Exemple : il y a les fichiers système («/etc/passwd», «/etc/hosts», «/etc/services»,...) il y a le DNS il y a NIS il y a NIS+ il y a LDAP etc. Comment choisir quels services répondront aux requêtes de recherche de nom? Une solution : préciser quels naming services seront utilisés et dans quel ordre au niveau du fichier «/etc/nsswitch.conf» (en anglais naming service switch). c T.Besançon (v ) Administration UNIX ARS Partie / 789

377 19 Sélection de naming services, /etc/nsswitch.conf 19.2 Syntaxe de Chapitre 19 Sélection de naming services, /etc/nsswitch.conf 19.2 Syntaxe de /etc/nsswitch.conf Le fichier est au format suivant : service: source [ status=action status=action... ] source... avec : pour source l un des mots clef «files», «dns», «ldap», «nis», «nisplus», «xfn» (liste à vérifier selon les systèmes UNIX offrant plus ou moins de ces services) pour status l un des mots clef suivants : «SUCCESS», entrée recherchée trouvée «NOTFOUND», entrée recherchée non trouvée «UNAVAIL», la source n est pas configurée sur ce système ou bien elle est défaillante «TRYAGAIN», la source est occupée et ne peut pas répondre actuellement, peut-être plus tard c T.Besançon (v ) Administration UNIX ARS Partie / Sélection de naming services, /etc/nsswitch.conf 19.2 Syntaxe de /etc/nsswitch.conf pour action l un des mots clefs : «return», retourner la valeur trouvée ou la non valeur «continue», essayer la source suivante «forever» (uniquement pour «TRYAGAIN»), persister sur cette source jusqu à avoir une réponse Par défaut, on a pour chaque source : [SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRYAGAIN=forever] c T.Besançon (v ) Administration UNIX ARS Partie / 789

378 19 Sélection de naming services, /etc/nsswitch.conf 19.3 Exemple de Chapitre 19 Sélection de naming services, /etc/nsswitch.conf 19.3 Exemple de /etc/nsswitch.conf (pris sur SOLARIS) passwd: files ldap group: files ldap hosts: ldap [NOTFOUND=return] files ipnodes: files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files netmasks: ldap [NOTFOUND=return] files bootparams: ldap [NOTFOUND=return] files publickey: ldap [NOTFOUND=return] files netgroup: ldap automount: files ldap aliases: files ldap... c T.Besançon (v ) Administration UNIX ARS Partie / Sélection de naming services, /etc/nsswitch.conf 19.4 A propos de LDAP Chapitre 19 Sélection de naming services, /etc/nsswitch.conf 19.4 A propos de LDAP Pour les systèmes n incorporant pas LDAP en natif dans l OS, se reporter à : « « c T.Besançon (v ) Administration UNIX ARS Partie / 789

379 Chapitre 20 Pluggable Authentication Module (PAM) c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.1 Problématique Chapitre 20 Pluggable Authentication Module (PAM) 20.1 Problématique Exemple : Soit une machine dans une université, hébergeant les comptes de 10 professeurs et de 1000 élèves. La machine est équipée d un modem. Les professeurs sont autorisés à se connecter à la machine par modem, pas les élèves. La machine est cliente NIS. Quand on se connecte par modem sur une machine, le système lance la commande «login» lorsque la connexion s établit. Comment implémenter cela? En modifiant le programme «login» pour l adapter à ce cas très particulier??? c T.Besançon (v ) Administration UNIX ARS Partie / 789

380 20 Pluggable Authentication Module (PAM) 20.1 Problématique La problématique en général : Comment changer une méthode d authentification dans un programme (par exemple FTP) sans avoir à tout reprogrammer? Solution développée par SUN à l origine et reprise et encouragée dans Linux : Pluggable Authentication Module dit PAM c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.2 Principe de PAM Chapitre 20 Pluggable Authentication Module (PAM) 20.2 Principe de PAM L authentication fait appel par l intermédiaire de PAM à des modules externes de code d authentification appropriée selon le service. On déporte l authentification en dehors du programme. /etc/pam.conf programme1 programme2 modulea.so moduleb.so modulec.so moduleb.so modulec.so programme1 pam_init() pam_auth() moduled.so modulee.so modulef.so programme2 pam_init() pam_auth() modulea.so moduleb.so modulec.so moduled.so modulee.so modulef.so c T.Besançon (v ) Administration UNIX ARS Partie / 789

381 20 Pluggable Authentication Module (PAM) 20.2 Principe de PAM 4 catégories de modules PAM : module d authentification (authentication) fonctionnalités pour authentifier un utilisateur et définir ses créances module de gestion de compte (account management) fonctionnalités pour déterminer si l utilisateur dispose d un compte valide (car possibilité d expiration de mot de passe dit password aging, de restrictions d accès horaire) module de gestion de session (session management) fonctionnalités pour définir et terminer les sessions utilisateur module de gestion de mot de passe (password management) fonctionnalités pour changer un mot de passe utilisateur et certaines caractéristiques du compte Pour une certaine application, on organise les modules nécessaires sous forme d une pile et chaque module de la pile va être essayé pour constituer l authentification demandée. Selon la configuration, un utilisateur pourra être amené à rentrer plusieurs mots de passe. c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.3 Configuration de : /etc/pam.conf, /etc/pam.d Chapitre 20 Pluggable Authentication Module (PAM) 20.3 Configuration de PAM : /etc/pam.conf, /etc/pam.d «/etc/pam.conf» définit quels modules seront utilisés pour chaque application. Sur Linux, on trouve aussi le répertoire «/etc/pam.d» qui contient un fichier par application portant le nom de l application. Ainsi «/etc/pam.d/login» pour le service «login». Une ligne de «/etc/pam.conf» contient 5 champs : service_name module_type control_flag module_path options c T.Besançon (v ) Administration UNIX ARS Partie / 789

382 20 Pluggable Authentication Module (PAM) 20.3 Configuration de PAM : /etc/pam.conf, /etc/pam.d service_name module_type control_flag module_path options Le «service_name» nomme le service concerné par la ligne («other» pour service joker) Le «module_type» est l un des 4 mots clef : «auth», «account», «session», «password» Le «control_flag» est l un des 4 mots clef : «requisite», «required», «optional», «sufficient» Le «module_path» est le chemin du module. Les options dépendent du module. c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.3 Configuration de PAM : /etc/pam.conf, /etc/pam.d Par exemple, le service «login» fait appel aux modules suivants : # Authentication management login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 # Account management login account requisite /usr/lib/security/pam_roles.so.1 login account required /usr/lib/security/pam_projects.so.1 login account required /usr/lib/security/pam_unix.so.1 # Session management other session required /usr/lib/security/pam_unix.so.1 # Password management other password required /usr/lib/security/pam_unix.so.1 c T.Besançon (v ) Administration UNIX ARS Partie / 789

383 20 Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules Chapitre 20 Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules Les directives possibles d essai des modules sont : directive «required» directive «requisite» directive «optional» directive «sufficient» c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules directive «required» La valeur de retour de ce module doit être «PAM_SUCCESS» pour sortir de la pile d authentification avec succès ; «PAM_AUTH_ERR» fera recommencer toute la pile : Pile de modules PAM REQUIRED SUCCESS AUTH_ERR c T.Besançon (v ) Administration UNIX ARS Partie / 789

384 20 Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules directive «requisite» Une valeur de retour «PAM_AUTH_ERR» fait sortir de la pile d authentification prématurément en échec : Pile de modules PAM REQUISITE SUCCESS AUTH_ERR c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules directive «optional» Si ce module échoue, on sortira de la pile avec succès si un autre module dans la pile réussit : Pile de modules PAM OPTIONAL SUCCESS AUTH_ERR c T.Besançon (v ) Administration UNIX ARS Partie / 789

385 20 Pluggable Authentication Module (PAM) 20.4 Directives d essai des modules directive «sufficient» Une valeur de retour «PAM_SUCCESS» de ce module fait sortir de la pile d authentification prématurément avec succès ; les autres modules dans la pile ne sont pas pris en compte : Pile de modules PAM SUFFICIENT AUTH_ERR SUCCESS c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.5 Modules, /usr/lib/security Chapitre 20 Pluggable Authentication Module (PAM) 20.5 Modules, /usr/lib/security Les modules sont conventionnellement stockés dans «/usr/lib/security/» Par exemple sur Solaris : % ls /usr/lib/security amiserv pam_ldap.so.1 pam_sample.so.1 pam_ami.so pam_projects.so pam_smartcard.so pam_ami.so.1 pam_projects.so.1 pam_smartcard.so.1 pam_dial_auth.so pam_rhosts_auth.so pam_unix.so pam_dial_auth.so.1 pam_rhosts_auth.so.1 pam_unix.so.1 pam_krb5.so pam_roles.so sparcv9 pam_krb5.so.1 pam_roles.so.1 pam_ldap.so pam_sample.so Chaque module fournit l implémentation d un mécanisme spécifique. c T.Besançon (v ) Administration UNIX ARS Partie / 789

386 20 Pluggable Authentication Module (PAM) 20.5 Modules, /usr/lib/security «/usr/lib/security/pam_unix.so.1» fournit un suport d authentification, gestion de compte, session de mot de passe. Il utilise les mots de passe UNIX pour l authenfication. «/usr/lib/security/pam_dial_auth.so.1» peut seulement être utilisé pour l authentification. Il utilise des données stockées dans «/etc/dialups» et «/etc/d_passwd». Principalement utilisé par «login». «/usr/lib/security/pam_rhosts_auth.so.1» peut seulement être utilisé pour l authentification. Il utilise les données stockées dans les fichiers «.rhosts» et «/etc/hosts.equiv». Principalement utilisé par «rlogin» et «rsh». c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.6 Options des modules Chapitre 20 Pluggable Authentication Module (PAM) 20.6 Options des modules On peut passer certaines options aux modules des options spécifiques à chaque module ; cf la documentation de chaque module ; par exemple «retry=3» ou «debug» option «use_first_pass» Cette option indique d utiliser exclusivement le mot de passe entré pour le premier module de la pile du service. option «try_first_pass» Cette option indique d utiliser d abord le mot de passe entré pour le premier module de la pile du service et en cas d échec de ce mot de passe d en demander un autre. (Le support des options «use_first_pass» et «try_first_pass» est fortement conseillé auprès des développeurs de modules PAM ; à vérifier donc avec chaque module) c T.Besançon (v ) Administration UNIX ARS Partie / 789

387 20 Pluggable Authentication Module (PAM) 20.7 Exemple 1 Chapitre 20 Pluggable Authentication Module (PAM) 20.7 Exemple 1 Extrait de «/etc/pam.conf» : # Authentication management login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 Fichier «/etc/dialups» : /dev/pts/9 Fichier «/etc/d_passwd» : /bin/bash:nuemrw70uy9m.: c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.7 Exemple 1 Session interactive : % tty /dev/pts/9 % exec login exec login login: besancon Password: XXXXXXXX <-- mot de passe Dialup Password: YYYYYYYY <-- mot de passe %% <-- connexion établie, shell lancé On voit bien la ligne supplémentaire «Dialup Password:» c T.Besançon (v ) Administration UNIX ARS Partie / 789

388 20 Pluggable Authentication Module (PAM) 20.7 Exemple 1 Si l on se trompe dans l un des mots de passe, toutes les demandes de mot de passe sont réessayées : % exec login login: besancon Password: ZZZZZZZZ <-- mauvais mot de passe Dialup Password: YYYYYYYY <-- mot de passe OK Login incorrect login: besancon Password: XXXXXXXX <-- mot de passe OK Dialup Password: ZZZZZZZZ <-- mauvais mot de passe Login incorrect login: besancon Password: XXXXXXXX <-- mot de passe OK Dialup Password: YYYYYYYY <-- mot de passe OK %% <-- connexion établie, shell lancé Au niveau SYSLOG, ça laisse quelques traces : Aug 20 14:51:14 cerise login: [ID auth.debug] pam_authenticate: error Authentication failed... Aug 20 14:51:34 cerise login: [ID auth.debug] pam_authenticate: error Authentication failed c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) 20.8 Exemple 2 Chapitre 20 Pluggable Authentication Module (PAM) 20.8 Exemple 2 Pour autoriser l authentification par LDAP, on mettra dans «/etc/pam.conf» : # Authentication management login auth sufficient /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_ldap.so.1 use_first_pass c T.Besançon (v ) Administration UNIX ARS Partie / 789

389 20 Pluggable Authentication Module (PAM) 20.9 A propos de LDAP Chapitre 20 Pluggable Authentication Module (PAM) 20.9 A propos de LDAP Pour les systèmes n incorporant pas LDAP en natif dans l OS, se reporter à : « c T.Besançon (v ) Administration UNIX ARS Partie / Pluggable Authentication Module (PAM) Un peu de bibliographie Chapitre 20 Pluggable Authentication Module (PAM) Un peu de bibliographie c T.Besançon (v ) Administration UNIX ARS Partie / 789

390 Chapitre 21 Système de multifenêtrage : X c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.1 Introduction : système de multi fenêtrage Chapitre 21 Système de multifenêtrage : X 21.1 Introduction : système de multi fenêtrage Système de multifenêtrage (Window System) : ensemble de programmes, de bibliothèques de programmation réalisant une interface homme / machine bâtie sur l utilisation de divers équipements : clavier souris écran graphique autres périphériques (spaceball, plaquette graphique,...) L écran tente de réaliser un modèle de bureau. L idée vient des travaux de Xerox, repris par Apple, repris par le projet Athena du MIT. c T.Besançon (v ) Administration UNIX ARS Partie / 789

391 21 Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Chapitre 21 Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Pour Unix, le système de multi fenêtrage est un système appelé : X ou X Window System ou X11 Ce n est pas «X Windows»! Historiquement : X11 sur «UNIX» XFree86 spécifiquement pour LINUX Xorg suite à querelles sur XFree86 = retour à l équipe de X11 c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Consortium de vendeurs d UNIX pour mettre au point X. Historique des versions : X10 X11R3 X11R4 X11R5 X11R6 X11R7 SUN a sa propre implémentation de X dérivée des X11R[3-7] : SUN OPENWINDOWS c T.Besançon (v ) Administration UNIX ARS Partie / 789

392 21 Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Le système graphique X est construit sur un modèle client serveur et est à la base un protocole de communication : Application X Message (dessine un cercle, etc.) Serveur X Affichage Reponse (OK, NOT OK, etc.) Erreur Evenement (clavier, clic souris, etc.) c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Serveur X : optimisé pour ses performances graphiques répond aux requêtes du client X envoie au client X des informations événementielles («clic du bouton droit de la souris», «appui sur la touche A avec Shift en même temps», etc.) Client X : effectue les calculs manipule les fichiers envoie des requêtes au serveur X («trace un cercle», «affiche du texte», «quelles sont les possibilités couleurs de l écran?», etc.) Souvent serveur X = client X = même machine. Parfois serveur X!= client X deux machines en réseau. Parfois! c T.Besançon (v ) Administration UNIX ARS Partie / 789

393 21 Système de multifenêtrage : X 21.2 Système de multifenêtrage : X Parfois serveur X!= client X deux machines en réseau. Parfois! C est donc un peu plus qu un système de multifenêtrage : il est réparti. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.3 Serveur X Chapitre 21 Système de multifenêtrage : X 21.3 Serveur X Serveur X : Au sens large : un serveur graphique Le serveur X gére les périphériques : écrans monochromes, niveaux de gris, couleurs, un ou plusieurs écrans souris, écran tactile, stylet, palette graphique claviers boutons, mollettes La configuration matérielle du serveur X peut varier considérablement (même si effet d unification suite à la mode du PC) le client X doit en tenir compte et doit s avoir s adapter. c T.Besançon (v ) Administration UNIX ARS Partie / 789

394 21 Système de multifenêtrage : X 21.3 Serveur X A noter qu il existe des serveurs X sur Windows et sur MacOS X. Sur Windows, utiliser CYGWIN (« : c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.4 Client X Chapitre 21 Système de multifenêtrage : X 21.4 Client X Client X : Client X == application L application doit être configurable : Environnement multi plateformes UNIX Environnement multi serveurs X Environnement multi utilisateurs L application ne doit jamais rien supposer du serveur X. Elle doit tenir compte de tous les cas envisageables et être paramétrée en conséquence. Nécessité que les applications soient configurables! c T.Besançon (v ) Administration UNIX ARS Partie / 789

395 21 Système de multifenêtrage : X 21.5 Chemins d accès Chapitre 21 Système de multifenêtrage : X 21.5 Chemins d accès On rencontre : Standard X11R4 et X11R5 : «/use/bin/x11/» «/use/lib/x11/» «/use/include/x11/» Standard X11R6 et X11R7 : «/use/x11r6/bin/» «/use/x11r6/lib/» «/use/x11r6/include/» Standard SUN OPENWINDOWS «/use/openwin/bin/» «/use/openwin/lib/» «/use/openwin/include/» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.6 Variable d environnement DISPLAY Chapitre 21 Système de multifenêtrage : X 21.6 Variable d environnement DISPLAY La variable «DISPLAY» définit le serveur X qui sera utilisé. Formes possibles de la variable : «nom-machine.domaine:numéro-serveur.numéro-écran» «adresse-ip:numéro-serveur.numéro-écran» «:0.0» (anciennement «unix:0.0») ; sens spécial de cette forme : communication locale rapide via IPC et non pas via le réseau TCP/IP plus lent dans ce cas On notera «numéro-serveur» : une même machine peut faire tourner plusieurs serveurs X d où la nécessité de les numéroter. Cas général : un seul serveur X numéro = 0. On notera «numéro-écran» : une même machine peut avoir plusieurs écrans d où la nécessité de les numéroter. Cas général : un seul écran numéro = 0. c T.Besançon (v ) Administration UNIX ARS Partie / 789

396 21 Système de multifenêtrage : X 21.6 Variable d environnement DISPLAY Exemples : «cerise.example.com:0.0» «localhost:11.0» «:0.0» « :0.0» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Chapitre 21 Système de multifenêtrage : X 21.7 Clavier La gestion du clavier est quelque chose de compliqué... Tous les types de claviers doivent pouvoir être supportés (FR, EN, RU, etc.). Par exemple des claviers braille : c T.Besançon (v ) Administration UNIX ARS Partie / 789

397 21 Système de multifenêtrage : X 21.7 Clavier Par exemple des boites à boutons ou à molettes (marque SILICON GRAPHICS) : c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Code clavier 1ere conversion SERVEUR X Keycode Shift 2eme conversion Alt Graph Keysym Keycode + Keysym + Status CLIENT X Alt, Num Lock, Alt Graph, Meta, Ctrl, Caps Lock, Shift c T.Besançon (v ) Administration UNIX ARS Partie / 789

398 21 Système de multifenêtrage : X 21.7 Clavier Keycode X définit une association entre le code généré par la touche du clavier et un code de la touche au niveau du serveur X : c est le keycode. Il existe un keycode et un seul par touche du clavier. On ne peut pas modifier l association entre le code du clavier et le keycode (sauf à recompiler le serveur X). On peut obtenir le keycode par l utilitaire «xev». c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Exemple de XEV : appui sur la touche «p» : % xev... KeyPress event, serial 20, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x2, keycode 26 (keysym 0x70, p), same_screen YES, XLookupString gives 1 characters: "p" KeyRelease event, serial 22, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x2, keycode 26 (keysym 0x70, p), same_screen YES, XLookupString gives 1 characters: "p"... c T.Besançon (v ) Administration UNIX ARS Partie / 789

399 21 Système de multifenêtrage : X 21.7 Clavier Exemple de XEV : appui sur la touche «p» avec SHIFT en même temps : % xev... KeyPress event, serial 22, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x2, keycode 232 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 characters: "" KeyPress event, serial 22, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x3, keycode 26 (keysym 0x50, P), same_screen YES, XLookupString gives 1 characters: "P" KeyRelease event, serial 22, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x3, keycode 26 (keysym 0x50, P), same_screen YES, XLookupString gives 1 characters: "P" KeyRelease event, serial 22, synthetic NO, window 0xc00001, root 0x2f, subw 0x0, time , (103,101), root:(927,454), state 0x3, keycode 232 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 characters: ""... c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Keysym X définit un nom symbolique pour chaque caractère utilisable. On parle de keysym. Le fichier «<X11/keysymdef.h>» définit les valeurs numériques de ces noms symboliques.... #define XK_dollar #define XK_percent #define XK_ampersand #define XK_apostrophe #define XK_parenleft #define XK_parenright #define XK_asterisk #define XK_plus #define XK_comma #define XK_minus #define XK_period #define XK_slash #define XK_0 #define XK_1 #define XK_2 #define XK_3 #define XK_4 0x024 0x025 0x026 0x027 0x028 0x029 0x02a 0x02b 0x02c 0x02d 0x02e 0x02f 0x030 0x031 0x032 0x033 0x034 #define XK_5 #define XK_6 #define XK_7 #define XK_8 #define XK_9 #define XK_colon #define XK_semicolon #define XK_less #define XK_equal #define XK_greater #define XK_question #define XK_at #define XK_A #define XK_B #define XK_C #define XK_D #define XK_E... 0x035 0x036 0x037 0x038 0x039 0x03a 0x03b 0x03c 0x03d 0x03e 0x03f 0x040 0x041 0x042 0x043 0x044 0x045 c T.Besançon (v ) Administration UNIX ARS Partie / 789

400 21 Système de multifenêtrage : X 21.7 Clavier Au démarrage du serveur X, il y a mise en place de correspondances entre keycode et keysyms. On peut modifier les correspondances via la commande «xmodmap». X accepte au maximum 5 keysyms pour un keycode via le jeu des modificateurs comme Shift, Ctrl, etc.. Exemple des modificateurs d une machine SOLARIS % xmodmap -pm xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0xe8), Shift_R (0xec) lock Control_L (0x40) control Control_L (0xe7), Control_R (0xeb) mod1 Meta_L (0xea), Meta_R (0xee) mod2 Mode_switch (0xed) mod3 Num_Lock (0x5a) mod4 Alt_L (0xe9) mod5 c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Liste des keycodes et de leurs keysyms associés (exemple pris sur une machine SUN avec un clavier QWERTY) : % xmodmap -pk There are 5 KeySyms per KeyCode; KeyCodes range from 8 to KeyCode Keysym (Keysym)... Value Value (Name) x0056 (V) 33 0x0057 (W) 34 0x0058 (X) 35 0x0059 (Y) 36 0x005a (Z) 37 0x0031 (1) 0x0021 (exclam) 38 0x0032 (2) 0x0040 (at) 39 0x0033 (3) 0x0023 (numbersign) 40 0x0034 (4) 0x0024 (dollar) 0x20ac (EuroSign) 41 0x0035 (5) 0x0025 (percent) 0x20ac (EuroSign) 42 0x0036 (6) 0x005e (asciicircum) 43 0x0037 (7) 0x0026 (ampersand) 44 0x0038 (8) 0x002a (asterisk) 45 0x0039 (9) 0x0028 (parenleft) 46 0x0030 (0) 0x0029 (parenright) c T.Besançon (v ) Administration UNIX ARS Partie / 789

401 21 Système de multifenêtrage : X 21.7 Clavier Liste des keycodes et de leurs keysyms associés avec affichage sous une forme compatible avec la syntaxe de XMODMAP pour les modifications (exemple pris sur une machine SUN avec un clavier QWERTY) : % xmodmap -pke... keycode 32 = V keycode 33 = W keycode 34 = X keycode 35 = Y keycode 36 = Z keycode 37 = 1 exclam keycode 38 = 2 at keycode 39 = 3 numbersign keycode 40 = 4 dollar EuroSign keycode 41 = 5 percent EuroSign keycode 42 = 6 asciicircum keycode 43 = 7 ampersand keycode 44 = 8 asterisk keycode 45 = 9 parenleft keycode 46 = 0 parenright... c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.7 Clavier Pour modifier le fonctionnement du clavier, deux syntaxes : «xmodmap -e keysym symbole = valeur» «xmodmap -e keycode code = valeur» Par exemple : on veut associer «é» à la touche «F2» (clavier SUN QWERTY) : Le keycode de «F2» est 66. Le keysym d origine associé à la touche est 0xffbf. Le keysym associé à «é» est d après «<X11/keysymdef.h>» 0x0e9 («XK_eacute»). «xmodmap -e keycode 66 = 0x0e9» A noter sur SOLARIS le script «/usr/openwin/bin/xmakemap» qui renvoie l image de la configuration actuelle du clavier. c T.Besançon (v ) Administration UNIX ARS Partie / 789

402 21 Système de multifenêtrage : X 21.8 Souris Chapitre 21 Système de multifenêtrage : X 21.8 Souris Tous les types de souris doivent pouvoir être supportés... c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X 21.8 Souris Plus classiquement : C est un outil de désignation ayant de 1 à 3 boutons. La position est suivie à l écran par un curseur. Le curseur est toujours affiché au premier plan. Pour permuter les boutons de la souris : «xmodmap -e pointer = 3 2 1» c T.Besançon (v ) Administration UNIX ARS Partie / 789

403 21 Système de multifenêtrage : X 21.9 Ecran Chapitre 21 Système de multifenêtrage : X 21.9 Ecran x y Il est de type bitmap (affichage point). L image est obtenue par balayage d une mémoire d écran (frame buffer) contenant une valeur par point à l écran (pixel). c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Fenêtre / icône Chapitre 21 Système de multifenêtrage : X Fenêtre / icône y x h Une fenêtre est un rectangle à l écran caractérisé par un emplacement, une bordure, ses dimensions. Une icône est la trace visible à l écran d une fenêtre temporairement non affichée. Les fenêtres sont organisées en arbre au niveau interne dans le serveur X. La racine de l arbre est la root window créée à l initialisation du serveur et couvrant tout l écran. Vulgairement, c est le fond d écran. w c T.Besançon (v ) Administration UNIX ARS Partie / 789

404 21 Système de multifenêtrage : X Copier / coller Chapitre 21 Système de multifenêtrage : X Copier / coller Pour copier, on sélectionne avec le bouton gauche de la souris. Pour coller, on clique avec le bouton du milieu de la souris. This is the text to select. All text around it is unselected. This is the text to select. All text around it is unselected. Modifiable. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Principe de personnalisation des clients Chapitre 21 Système de multifenêtrage : X Principe de personnalisation des clients Personnalisation via des ressources ou des arguments de la ligne de commande : O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande c T.Besançon (v ) Administration UNIX ARS Partie / 789

405 21 Système de multifenêtrage : X Options de la ligne de commande Chapitre 21 Système de multifenêtrage : X Options de la ligne de commande Il y a des options standard pour la plupart des clients car leur programmation s appuye sur une bibliothèque appelée «Xt». Exemples : display : «-display cerise.example.com:0.0» couleur des caractères : «-fg couleur» couleur de fond des fenêtres : «-bg couleur» caractères : «-fn font» dimensions et emplacement de la fenêtre : «-geometry WIDTH HEIGHT±XOFF±YOFF» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Options de la ligne de commande Retour sur l option «-geometry WIDTH HEIGHT±XOFF±YOFF» : X X Y Y Y Y X X c T.Besançon (v ) Administration UNIX ARS Partie / 789

406 21 Système de multifenêtrage : X Ressources Chapitre 21 Système de multifenêtrage : X Ressources Une ressource = variable configurée dans un fichier ASCII (analogie : base de registres de Windows ou ressources Macintosh) 4 niveaux de ressources : ressources définies par le système ressources définies par le client X ressources définies par le serveur X ressources définies par l utilisateur O R D R E D E R E C H E R C H E $XFILESEARCHPATH ou /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH ou $XAPPLRESDIR ou $HOME propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources Ressources définies par le système O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande Traditionnellement «/usr/x11r6/lib/x11/app-defaults/». Ce répertoire regroupe les fichiers correspondants aux classes des applications. Par exemple «XTerm» pour l application X «xterm», «Bitmap» pour l application X «bitmap», etc. Ces ressources sont lues par les clients X qui tournent sur la machine de ce répertoire. c T.Besançon (v ) Administration UNIX ARS Partie / 789

407 21 Système de multifenêtrage : X Ressources Ressources définies par le client X O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande Traditionnellement «$HOME». Ce mécanisme s applique aux applications X développées avec la librairie «Xt». Le fichier de ressources porte le nom de l application. Par exemple «XTerm» pour l application X «xterm», «Bitmap» pour l application X «bitmap», etc. Ces ressources sont lues par les clients X qui tournent sur la machine de ce répertoire. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources Ressources définies par le serveur X O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande Des ressources peuvent être placées dans une base de données dans la mémoire du serveur X. Ces ressources sont donc communes à tous les clients de ce serveur X. Les clients les lisent lors de leur démarrage, plus après. La commande «xrdb» sert à manipuler cette base de données en mémoire dans le serveur X. c T.Besançon (v ) Administration UNIX ARS Partie / 789

408 21 Système de multifenêtrage : X Ressources Ressources définies par l utilisateur O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande Ce mécanisme permet d avoir un fichier propre à plusieurs systèmes même si le homedir est partagé (via NFS) entre ces systèmes. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources Syntaxes des ressources Syntaxes : «nom-application.attribut: valeur» «classe.nom.sous-nom...attribut: valeur» Par exemple : xterm.background: black xterm.foreground: yellow c T.Besançon (v ) Administration UNIX ARS Partie / 789

409 21 Système de multifenêtrage : X Ressources Un client X est construit autour d un arbre de «widgets» (boutons, dropdown menus, etc.) fournis par les bibliothèques de programmation. On a en fait une arborescence de ressources. Programme «editres» pour les manipuler. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources La syntaxe utilise des caractères «joker» : caractère «.» : séparateur des éléments dans la définition de la ressource caractère «*» : permet de remplacer un ou plusieurs éléments dans la définition de la ressource caractère «?» : permet de remplacer un et un seul élément dans la définition de la ressource Par exemple : xterm.background: black xterm.foreground: yellow c T.Besançon (v ) Administration UNIX ARS Partie / 789

410 21 Système de multifenêtrage : X Ressources Notion de : classe application de la classe fenêtre d une application C est la ressource la plus précise qui est prise en compte. Par exemple : «mon-application.sous-fenêtre.side.background: yellow» prime sur «mon-application.sous-fenêtre.background: blue» qui prime sur «mon-application.background: red» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources xrdb Rappel : O R D R E D E ou ou ou $XFILESEARCHPATH /usr/x11r6/lib/x11/app-defaults $XUSERFILESEARCHPATH $XAPPLRESDIR $HOME R E C H E R C H E propriete RESOURCE_MANAGER (xrdb) ou $HOME/.Xdefaults $XENVIRONMENT ou $HOME/.Xdefaults-nom-host Arguments de la ligne de commande Des ressources peuvent être placées dans une base de données dans la mémoire du serveur X. La commande «xrdb» sert à manipuler cette base de données en mémoire dans le serveur X. xrdb = X server Resource DataBase utility c T.Besançon (v ) Administration UNIX ARS Partie / 789

411 21 Système de multifenêtrage : X Ressources Syntaxes : «xrdb -query» : liste les ressources actuelles du serveur X «xrdb -merge fichier» : fusionne un fichier de ressources avec les ressources du serveur X «xrdb -load fichier» : écrase les ressources du serveur X par celles du fichier indiqué «xrdb -remove» : efface les ressources du serveur X «xrdb -symbols» : affiche la liste des symboles prédéfinis (voir ci-dessus pour la partie CPP) «xrdb» utilise «cpp» du langage C. Donc le fichier de ressources à charger peut contenir les directives classiques de CPP : «#include» «#ifdef» etc. Intérêt : un seul fichier mais pouvant traiter plusieurs cas de figures. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Ressources Par exemple : #ifndef COLOR XTerm*cursorColor: black XTerm*pointerColor: black #else /* COLOR is DEFINED :-) */ XTerm*cursorColor: red XTerm*pointerColor: red #endif c T.Besançon (v ) Administration UNIX ARS Partie / 789

412 21 Système de multifenêtrage : X Couleurs Chapitre 21 Système de multifenêtrage : X Couleurs On peut désigner une couleur sous un nom symbolique : «/usr/x11r6/lib/x11/rgb.txt» définit ainsi 738 couleurs (les noms ne sont pas forcément parlants). Par exemple : «Pink» On peut aussi donner une couleur via ses composantes Rouge Vert Bleu (RGB en anglais) sous la forme «rgb:red/green/blue». Ainsi «Pink» équivaut à «rgb:255/192/203». Ancienne syntaxe supportée pour compatibilité : #RGB #RRGGBB #RRRGGGBBB #RRRRGGGGBBBB (4 bits each) (8 bits each) (12 bits each) (16 bits each) c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Couleurs A partir de X11R5, adoption de la gestion des couleurs via X Color Management System (XCMS). Le fichier «/usr/x11r6/lib/x11/xcms.txt» décrit des couleurs. Par exemple : XCMS_COLORDB_START 0.1 red green blue aquamarine cadet blue cornflower blue navy blue navy brown gray0 gray10 gray20... gray80 gray90 gray100 XCMS_COLORDB_END CIEXYZ:0.3811/0.2073/ CIEXYZ:0.3203/0.6805/ CIEXYZ:0.2483/0.1122/ CIEXYZ:0.5512/0.7909/ CIEXYZ:0.2218/0.2815/ CIEXYZ:0.3400/0.3109/ CIEXYZ:0.0478/0.0216/ CIEXYZ:0.0478/0.0216/ CIEXYZ:0.1333/0.0772/ TekHVC:0.0/0.0/0.0 TekHVC:0.0/10.0/0.0 TekHVC:0.0/20.0/0.0 TekHVC:0.0/80.0/0.0 TekHVC:0.0/90.0/0.0 TekHVC:0.0/100.0/0.0 Commande associée : «xcmsdb» c T.Besançon (v ) Administration UNIX ARS Partie / 789

413 21 Système de multifenêtrage : X Polices de caractères Chapitre 21 Système de multifenêtrage : X Polices de caractères Les fontes ont des noms très détaillés. Par exemple : -adobe-courier-medium-r-normal m-60-iso «adobe» : concepteur de la police «courier» : famille de la police «medium» : graisse (bold, medium, extra bold, light, etc.) «r» : angle (roman, italic, etc.) «normal» : largeur (normal, narrow, etc.) vide : style complémentaire «10» : hauteur en pixels «100» : hauteur en points (un point = 1/72e de pouce) «75» : résolution horizontale de conception de la police «75» : résolution verticale de conception de la police «m» : espacement (p = proportionnel, m = monospace, etc.) «60» : largeur moyenne en 1/10e de pixel «iso8859-1» : jeu de caractères c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Polices de caractères Plusieurs formats sont possibles. Liste non exhaustive : BDF (Bitmap Distribution Format), SNF (Server Natural Font), PCF (Portable Compiled Font), Type1 PostScript depuis X11R6, True Type ( PEX, Speedo c T.Besançon (v ) Administration UNIX ARS Partie / 789

414 21 Système de multifenêtrage : X Polices de caractères On peut utiliser la commande «xlsfonts» pour avoir la liste des fontes utilisables sur son poste X. Les polices sont utilisables via les ressources. Par exemple : XTerm*Font: Emacs*paneFont: 7x13bold -adobe-times-medium-r-normal p-74-iso Les polices sont utilisables via la ligne de commande. Par exemple : % xfd -fn 9x15bold c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Polices de caractères Les fontes sont stockées dans l arborescence «/usr/x11r6/lib/x11/fonts/» contenant plusieurs sous répertoires dont : «75dpi/» : polices de résolution de 75 dpi «100dpi/» : polices de résolution de 100 dpi «misc/» : polices diverses Notion de font path. Configuration du font path via la commande «xset» : «xset -q» «xset +fp /chemin/vers/répertoire/de/fontes/» «xset fp+ /chemin/vers/répertoire/de/fontes/» «xset -fp /chemin/vers/répertoire/de/fontes/» «xset fp rehash» L ordre des répertoires est significatif. c T.Besançon (v ) Administration UNIX ARS Partie / 789

415 21 Système de multifenêtrage : X Répertoires de polices de caractères Chapitre 21 Système de multifenêtrage : X Répertoires de polices de caractères Un répertoire de polices de caractères a une structure précise : % ls /usr/x11r6/lib/x11/fonts/misc 10x20.pcf.Z Screen6.pcf.Z clr8x10.pcf.z 12x24.pcf.Z Screen7.pcf.Z clr8x12.pcf.z 12x24rk.pcf.Z Serif10.pcf.Z clr8x13.pcf.z 5x7.pcf.Z Serif11.pcf.Z clr8x14.pcf.z 5x8.pcf.Z Serif12.pcf.Z clr8x16.pcf.z 6x10.pcf.Z Serif14.pcf.Z clr8x8.pcf.z 6x12.pcf.Z Serif16.pcf.Z clr9x15.pcf.z 6x13.pcf.Z clb6x10.pcf.z cursor.pcf.z 6x13B.pcf.Z clb6x12.pcf.z deccurs.pcf.z 6x9.pcf.Z clb8x10.pcf.z decsess.pcf.z 7x13.pcf.Z clb8x12.pcf.z fonts.alias 7x13B.pcf.Z clb8x13.pcf.z fonts.dir... c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Répertoires de polices de caractères Fichier «fonts.dir» : ce fichier contient la liste des polices du répertoire ; plus exactement des lignes au format : «fichier-de-la-police nom-x-de-la-police». Par exemple :... 6x13.pcf.Z -misc-fixed-medium-r-semicondensed c-60-iso Fichier «fonts.alias» : ce fichier contient des alias plus parlant que les noms complets des polices X. Par exemple :... fixed... "-misc-fixed-medium-r-semicondensed c-60-iso8859-1" L ajout d une fonte ne se résume pas à copier le fichier de la fonte dans le répertoire! c T.Besançon (v ) Administration UNIX ARS Partie / 789

416 21 Système de multifenêtrage : X Répertoires de polices de caractères Pour ajouter une police, il faudra faire appel à la commande «mkfontdir» : 1 créer le répertoire des polices si nécessaire : «mkdir /tmp/fonts» 2 copier la police dans le répertoire : «cp toto.pcf /tmp/fonts» 3 créer le fichier «fonts.dir» : «mkfontdir» 4 créer éventuellement des alias : «vi /tmp/fonts/fonts.alias» 5 ajouter le nouveau répertoire à son font path : «xset +fp /tmp/fonts/» ; Attention : il faut le slash final «/tmp/fonts/» 6 reconstituer la liste à jour des polices X : «xset fp rehash» 7 vérification des polices disponibles : «xlsfonts» ou «xset -q» 8 utilisation des nouvelles polices : «application-x.exe -fn nouvelle-fonte» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Serveur de polices de caractères Chapitre 21 Système de multifenêtrage : X Serveur de polices de caractères L ajout de polices X sur un parc de machines est une opération pénible (voir transparent précédent). Apparition d un mécanisme de serveur de fontes X. Administration simplifiée car centralisation des polices. En X11R5 : programme «fs». En X11R6 et après : programme «xfs». c T.Besançon (v ) Administration UNIX ARS Partie / 789

417 21 Système de multifenêtrage : X Serveur de polices de caractères Syntaxe : «xfs [-config fichier-config] [-port n]» Par défaut le fichier de configuration est «/etc/x11/fs/config». Par défaut le port TCP utilisé est 7100 (voir «/etc/services»). c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Serveur de polices de caractères Exemple de fichier de configuration : # allow a max of 10 clients to connect to this font server client-limit = 10 catalogue = /chemin/vers/fonts/ibm, /chemin/vers/fonts/ooffice, /chemin/vers/fonts/cmps, /chemin/vers/fonts/mathematica, /chemin/vers/fonts/msttcorefonts, /usr/x11r6/lib/x11/fonts/korean, /usr/x11r6/lib/x11/fonts/misc:unscaled, /usr/x11r6/lib/x11/fonts/75dpi:unscaled, /usr/x11r6/lib/x11/fonts/100dpi:unscaled, /usr/x11r6/lib/x11/fonts/type1, /usr/x11r6/lib/x11/fonts/cyrillic,... # how to log errors use-syslog = on # don t listen to TCP ports by default for security reasons # no-listen = tcp port = 7100 c T.Besançon (v ) Administration UNIX ARS Partie / 789

418 21 Système de multifenêtrage : X Serveur de polices de caractères Utilisation d un serveur de fontes par : «xset +fp tcp/xfs.example.com:7100» Liste des polices d un serveur de fontes par : «fslsfonts -server tcp/xfs.example.com:7100» Test du serveur serveur de fontes par : «fsinfo -server tcp/xfs.example.com:7100» c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Gestionnaire de fenêtres, window manager Chapitre 21 Système de multifenêtrage : X Gestionnaire de fenêtres, window manager Gestionnaire de fenêtres Window Manager client X au même titre que les autres. Il permet de réaliser les choses suivantes : déplacer ou redimensionner une fenêtre iconifier ou non une fenêtre faire passer au premier ou au dernier plan une fenêtre décorer les fenêtres créer ou détruire les fenêtres lancer ou terminer des applications L emploi d un gestionnaire de fenêtres n a rien d obligatoire mais ce serait se priver de beaucoup de fonctionnalités. Il ne faut pas confondre le gestionnaire de fenêtres avec le serveur X. c T.Besançon (v ) Administration UNIX ARS Partie / 789

419 21 Système de multifenêtrage : X Gestionnaire de fenêtres, window manager Quelques exemples de fenêtres décorées par des window managers : c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE Chapitre 21 Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE Sur une station avec une mire d accueil graphique, le script «$HOME/.xsession» est lancé lors de la connexion et il configure l environnement graphique de l utilisateur : applications X à lancer automatiquement au démarrage (par exemple des terminaux) réglages du clavier réglages de la souris etc. La durée de vie de la session sous X est celle du script «$HOME/.xsession». c T.Besançon (v ) Administration UNIX ARS Partie / 789

420 21 Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE Forme générale du script «$HOME/.xsession» : #!/bin/sh client-x-1 & client-x-2 &... applix <--- pas de & Le dernier client X n est pas lancé en tâche de fond (sinon le script s arrête tout de suite et la session se ferme brutalement). En général, le dernier client est le window manager. c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE S il y a des erreurs, les messages de celles-ci sont écrits dans le fichier «$HOME/.xsession-errors». En cas d erreur grave dans «$HOME/.xsession» empêchant le démarrage de la session X, utiliser le mode FailSafe : disponible via les menus de la fenêtre d accueil de KDE disponible via les menus de la fenêtre d accueil de GNOME dans l environnement de base X : 1 entrer le nom de login 2 valider par la touche Retour 3 entrer le mot de passe 4 valider par la touche F1 et non pas par la touche Retour Il apparait alors un simple xterm sans window manager. L utiliser pour corriger les erreurs indiquées dans le fichier «$HOME/.xsession-errors». c T.Besançon (v ) Administration UNIX ARS Partie / 789

421 21 Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE Version KDE du FAILSAFE : via un menu : c T.Besançon (v ) Administration UNIX ARS Partie / Système de multifenêtrage : X Configuration de la session X, $HOME/.xsession, FAILSAFE c T.Besançon (v ) Administration UNIX ARS Partie / 789