/usr/share/doc/HOWTO/fr-html/NFS-HOWTO.html is in doc-linux-fr-html 2013.01-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>Linux NFS HOWTO</title>
</head>
<body>
<h1>Linux NFS HOWTO</h1>
<h2>Nicolai Langfeldt <code>janl@linpro.no</code></h2>
v1.0, 1er octobre 1999
<hr>
<em>(30 novembre 1999. Adaptation française par Christophe
Deleuze, <code>Christophe.Deleuze@lip6.fr</code>). HOWTO
décrivant l'installation de serveurs et clients NFS.</em>
<hr>
<h2><a name="s1">1. Préambule</a></h2>
<h2><a name="ss1.1">1.1 Blabla légal</a></h2>
<p>(C)opyright 1997-1999 Nicolai Langfeldt et Ron Peters. Si vous
modifiez ce document signalez le dans le copyright, sa distribution
est libre à condition de conserver ce paragraphe. La section
FAQ est basée sur la FAQ NFS compilée par Alan Cox.
La section <em>Checklist</em> est basée sur une
<em>checklist</em> des problèmes de mount compilée
par IBM Corporation. La section ``NFS serveur sur disquette'' a
été écrite par Ron Peters.</p>
<p>(C)opyright 1997-1999 Christophe Deleuze pour la version
française. Si vous lisez ce document sous le pont de l'Alma,
veillez à respecter les limitations de vitesse.</p>
<h2><a name="ss1.2">1.2 Dénégation</a></h2>
<p>Ni Nicolai Langfeldt, ni Ron Peters ni leurs employeurs, ni qui
que ce soit, n'assume de responsabilité pour les
conséquences que les instructions de ce document peuvent
avoir. Si vous choisissez de suivre ces instructions, bonne chance
!</p>
<h2><a name="ss1.3">1.3 Retour</a></h2>
<p>Ce document ne sera jamais terminé, merci de m'envoyer
par mail vos problèmes et réussites, cela pourra
améliorer ce HOWTO. Envoyez argent, commentaires et
questions à <a href=
"mailto:janl@math.uio.no">janl@math.uio.no</a>, ou <a href=
"mailto:rpeters@hevanet.com">rpeters@hevanet.com</a> pour ce qui
concerne les serveurs NFS sur disquette. Si vous m'envoyez un mail,
par pitié, <em>vérifiez</em> que l'adresse de retour
soit correcte et fonctionne. Vous ne vous imaginez pas combien de
mes réponses sont revenues à cause d'une adresse
incorrecte.</p>
<h2><a name="ss1.4">1.4 Autre blabla</a></h2>
<p>Si vous voulez traduire ce HOWTO merci de me le signaler, que je
puisse savoir en quels langages j'ai été
publié :-). [Ndt : c'est fait...]</p>
<p>Remerciements à Olaf Kirch pour m'avoir convaincu
d'écrire ceci, puis fourni de bonnes suggestions.</p>
<p>Les commentaires sur la traduction sont à envoyer
à Christophe Deleuze, Christophe.Deleuze@lip6.fr.</p>
<h2><a name="intro"></a> <a name="s2">2. LISEZMOI.d_abord</a></h2>
<p>NFS, le système de fichiers par réseau, a trois
caractéristiques importantes :</p>
<ul>
<li>il permet le partage de fichiers sur un réseau ;</li>
<li>il marche suffisamment bien ;</li>
<li>il crée tout un tas de problèmes de
sécurité bien connus des crackers qui peuvent
facilement les exploiter pour obtenir l'accès (lecture,
écriture et effacement) à tous vos fichiers.</li>
</ul>
<p>Je parlerai de ces deux aspects dans ce HOWTO. Lisez bien la
section sécurité et vous supprimerez quelques risques
stupides. Ne dites pas que je ne vous ai pas prévenus. Les
passages sur la sécurité sont parfois assez
techniques et demandent quelques connaissances en réseau IP.
Si vous ne connaissez pas les termes utilisés vous pouvez
soit consulter le HOWTO réseau, improviser ou vous procurer
un livre sur l'administration de réseau TCP/IP pour vous
familiariser avec TCP/IP. C'est une bonne idée de toutes
façons si vous administrez des machines UNIX/Linux. Un
très bon livre sur le sujet est <em>TCP/IP Network
Administration</em> par Craig Hunt, publié par O'Reilly
& Associates, Inc. Et quand vous l'aurez lu et compris, vous
vaudrez plus cher sur le marché du travail, vous ne pouvez
qu'y gagner :-)</p>
<p>Il y a deux sections pour vous aider à régler vos
problèmes NFS, la <em>Mount Checklist</em> et les
<em>FAQs</em>. Jetez-y un oeil si quelque chose ne marche pas comme
prévu.</p>
<p>Si vous voulez/avez besoin de le récupérer et
compiler vous même, le site de référence pour
le nfsd Linux 2.0 est <a href=
"ftp.mathematik.th-darmstadt.de:/pub/linux/okir">ftp.mathematik.th-darmstadt.de:/pub/linux/okir</a>.</p>
<p>À propos de NFS sous Linux 2.2 voir <a href=
"#linuxtwotwo">la section sur Linux 2.2</a>.</p>
<h2><a name="nfs-server"></a> <a name="s3">3. Installer un serveur
NFS</a></h2>
<h2><a name="ss3.1">3.1 Conditions préalables</a></h2>
<p>Avant de continuer à lire ce HOWTO, vous aurez besoin de
pouvoir faire des telnet dans les deux sens entre les machines que
vous utiliserez comme serveur et client. Si cela ne fonctionne pas,
voyez le HOWTO réseau (NET-3) et configurez correctement le
réseau.</p>
<h2><a name="ss3.2">3.2 Premiers pas</a></h2>
<p>Avant de faire quoi que ce soit d'autre, il nous faut un serveur
NFS installé. Si vous faites partie d'un département
réseau d'une université ou autre, il y a probablement
un grand nombre de serveurs NFS qui tournent déjà. Si
votre but est d'utiliser un serveur déjà
installé alors vous pouvez sauter à <a href=
"#nfs-client">la section sur l'installation d'un client
NFS</a>.</p>
<p>Si vous devez installer un serveur sur une machine non Linux
vous devrez lire les pages de manuel du système pour trouver
comment configurer le serveur NFS et l'exportation des
systèmes de fichiers par NFS. Ce HOWTO contient une section
décrivant les manipulations nécessaires sur divers
systèmes. Ceci fait, vous pourrez passer à la section
suivante. Ou continuer à lire cette section vu que certaines
des choses que je vais dire sont pertinentes quel que soit le type
de machine que vous utilisez comme serveur.</p>
<p>Si vous utilisez Linux 2.2, voyez <a href="#linuxtwotwo">la
section sur Linux 2.2</a> avant de passer à la suite.</p>
<p>Nous allons maintenant configurer tout un tas de programmes.</p>
<h2><a name="ss3.3">3.3 Le portmapper</a></h2>
<p>Le portmapper de Linux est appelé soit
<code>portmap</code> soit <code>rpc.portmap</code>. La page de
manuel sur mon système dit que c'est un convertisseur de
port DARPA vers numéro de programme RPC. C'est là que
se trouve la première faille de sécurité. La
gestion de ce problème est décrite à la
section <a href="#nfs-security">sur la sécurité</a>,
que, encore une fois, je vous invite très fortement à
lire.</p>
<p>Lancez le portmapper. Il devrait être dans le
répertoire <code>/usr/sbin</code> (sur quelques machines il
est appelé rpcbind). Vous pouvez le lancer à la main
pour cette fois mais il devra être lancé à
chaque démarrage de la machine, il faudra donc créer
ou éditer les scripts rc. Les scripts rc sont décrits
dans la page de manuel init, ils sont généralement
dans <code>/etc/rc.d</code>, <code>/etc/init.d</code> ou
<code>/etc/rc.d/init.d</code>. S'il y a un script qui a un nom du
genre <code>inet</code>, c'est probablement le script à
éditer. Mais ce qu'il faut écrire ou faire sort du
cadre de ce HOWTO. Lancez portmap, et vérifiez qu'il tourne
avec <code>ps -aux</code>, puis <code>rpcinfo -p</code>. Il y est ?
Benissimo.</p>
<p>Encore une chose. L'accès distant à votre
portmapper est contrôlé par le contenu de vos fichiers
<code>/etc/hosts.allow</code> et <code>/etc/hosts.deny</code>. Si
<code>rcpinfo -p</code> échoue alors que le portmapper
tourne, vérifiez ces fichiers. Voyez la section <a href=
"#nfs-security">sur la sécurité</a> pour les
détails concernant ces fichiers.</p>
<h2><a name="ss3.4">3.4 Mountd et nfsd</a></h2>
<p>Les prochains programmes à lancer sont mountd et nfsd.
Mais d'abord il faut éditer un autre fichier,
<code>/etc/exports</code>. Disons que je veux que le système
de fichiers <code>/mn/eris/local</code> qui est sur la machine
<code>eris</code> soit disponible sur la machine
<code>apollon</code>. Je l'indique dans <code>/etc/exports</code>
sur eris :</p>
<hr>
<pre>
/mn/eris/local apollon(rw)
</pre>
<hr>
<p>La ligne ci-dessus donne à <code>apollon</code> un
accès en lecture/écriture sur
<code>/mn/eris/local</code>. Au lieu de <code>rw</code> on pourrait
mettre <code>ro</code> pour <em>read only</em> (lecture seule,
c'est la valeur par défaut). D'autres options existent, et
je parlerai de quelques unes liées à la
sécurité plus loin. Elles sont toutes décrites
dans la page de manuel <code>exports</code> qu'il faut lire au
moins une fois dans sa vie. Il y a de meilleures façons de
faire que de lister tous les hosts dans le fichier exports. Peuvent
être autorisés à monter un système de
fichiers NFS, des groupes réseaux (<em>net groups</em>) si
vous utilisez NIS (ou NYS, auparavant connu sous le nom YP), des
noms de domaines avec jokers et des sous réseaux IP. Mais il
faudra vérifier qui peut obtenir un accès au serveur
avec ce type d'autorisations groupées.</p>
<p>Note : ce fichier exports n'utilise pas la même syntaxe
que d'autres Unix. Ce HOWTO contient une section sur la
façon dont les autres Unix <code>export</code>ent leurs
fichiers.</p>
<p>Maintenant nous sommes prêts à lancer mountd (ou
peut-être s'appelle-t-il <code>rpc.mountd</code>), puis nfsd
(qui s'appelle peut-être <code>rpc.nfsd</code>). Ils liront
tous deux le fichier exports.</p>
<p>Si vous modifiez <code>/etc/exports</code>, vous devrez vous
assurer que nfsd et mountd savent que le fichier a changé.
La façon traditionnelle est de lancer <code>exportfs</code>.
Beaucoup de distributions Linux n'ont pas le programme exportfs. Si
c'est le cas sur votre machine, vous pouvez installer ce script
:</p>
<hr>
<pre>
#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
echo Volumes NFS réexportés
</pre>
<hr>
<p>Sauvez le dans <code>/usr/sbin/exportfs</code> par exemple, et
n'oubliez pas de lui appliquer <code>chmod a+rx</code>.
Désormais, chaque fois que vous changez votre fichier
exports, lancez ensuite exportfs en root.</p>
<p>Maintenant, vérifiez que mountd et nfsd fonctionnent
correctement. D'abord avec <code>rpcinfo -p</code>. Il devrait
donner quelque chose du genre :</p>
<hr>
<pre>
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 745 mountd
100005 1 tcp 747 mountd
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs
</pre>
<hr>
<p>On voit que le portmapper a annoncé ses services, de
même que mountd et nfsd.</p>
<p>Si vous obtenez : <code>rpcinfo: can't contact portmapper: RPC:
Remote system error - Connection refused</code>,
<code>RPC_PROG_NOT_REGISTERED</code> ou quelque chose du style
c'est que le portmapper ne tourne pas. OU, vous avez quelques chose
dans <code>/etc/hosts.{allow,deny}</code> qui interdit au
portmapper de répondre, voyez <a href="#nfs-security">la
section sécurité</a> à ce propos. Si vous
obtenez <code>No remote programs registered</code> alors soit le
portmapper ne veut pas vous parler, soit quelque chose ne marche
pas. Tuez nfsd, mountd et le portmapper et essayez de
recommencer.</p>
<p>Après avoir vérifié que le portmapper rend
compte des services vous pouvez vérifier aussi avec
<code>ps</code>. Le portmapper continuera à afficher les
services même si les programmes qui les offrent ont
crashé. Il vaut donc mieux vérifier par ps si quelque
chose ne marche pas.</p>
<p>Bien sur, vous devrez modifier vos fichiers systèmes rc
pour lancer mountd et nfsd au démarrage de la même
façon que le portmapper. Il y a de très fortes
chances que les scripts existent déjà sur votre
machine, vous aurez juste à décommenter les bonnes
lignes ou les activer pour les bons <em>runlevels</em> (pardon
niveaux d'exécution) d'init.</p>
<p>Quelques pages de manuel avec lesquelles vous devriez être
familier : portmap, mountd, nfsd et exports.</p>
<p>Bon, si vous avez tout fait exactement comme j'ai dit vous
êtes prêts à enchaîner sur le client
NFS.</p>
<h2><a name="nfs-client"></a> <a name="s4">4. Installer un client
NFS</a></h2>
<p>Tout d'abord il faudra compiler un noyau avec le système
de fichiers NFS, soit compilé dans le noyau, soit disponible
sous forme de module. Si vous n'avez encore jamais compilé
un noyau vous aurez peut être besoin de consulter le HOWTO du
noyau. Si vous utilisez une distribution très cool (comme
Chapeau Rouge) et que vous n'avez jamais trifouillé le noyau
(pas toucher toucher) il y a des chances que NFS soit
automagiquement disponible.</p>
<p>Vous pouvez maintenant, à l'invite (prompt) du root,
entrer la commande <code>mount</code> appropriée et le
système de fichiers apparaîtra. Continuons avec
l'exemple de la section précédente, nous voulons
monter <code>/mn/eris/local</code> depuis eris. La commande est
:</p>
<hr>
<pre>
mount -o rsize=1024, wsize=1024 eris:/mn/eris/local /mnt
</pre>
<hr>
<p>Nous reviendrons plus tard sur les options rsize et wsize. Le
système de fichiers est maintenant disponible sous /mnt et
vous pouvez faire un cd sur lui, puis un ls et regarder les
fichiers individuellement. Vous remarquerez que ce n'est pas aussi
rapide qu'avec un système de fichiers local, mais beaucoup
plus pratique que ftp. Si, au lieu de monter le système de
fichiers, mount renvoie un message d'erreur comme <code>mount:
eris:/mn/eris/local failed, reason given by server: Permission
denied</code> alors le fichier exports est incorrect, ou vous avez
oublié de lancer exportfs après avoir modifié
le fichier exports. S'il dit <code>mount: clntudp_ipdate: RPC:
Program not registered</code> cela signifie que nfsd ou mountd ne
tourne pas sur le serveur, ou que vous avez le problème avec
les fichiers <code>hosts.{allow,deny}</code> mentionné plus
haut.</p>
<p>Pour vous débarrasser du système de fichiers, vous
pouvez faire :</p>
<hr>
<pre>
umount /mnt
</pre>
<hr>
<p>Pour que le système monte automatiquement un
système de fichiers NFS au démarrage, éditez
<code>/etc/fstab</code> de la façon habituelle. Par exemple
avec une ligne comme celle-ci :</p>
<hr>
<pre>
# device mountpoint fs-type options dumps sfckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0
...
</pre>
<hr>
<p>C'est presque tout ce qu'il y a à savoir. Vous pouvez
jeter un coup d'oeil à la page de manuel <code>nfs</code>.
Continuons plize.</p>
<h2><a name="ss4.1">4.1 Options de montage</a></h2>
<p>Il y a trois comportements principaux des clients NFS en cas de
chute du serveur qui sont spécifiés par les options
de montage :</p>
<dl>
<dt><b>soft</b></dt>
<dd>
<p>Le client NFS renverra une erreur au processus concerné
si après quelques essais le serveur NFS persiste à ne
pas répondre. Si vous voulez utiliser cette option, vous
devez vérifier que votre logiciel la gère
correctement. Je ne recommande pas ce réglage, c'est un bon
moyen de perdre des données et corrompre des fichiers. En
particulier, n'utilisez pas ça pour les disques où
sont stockés vos mails (si vous tenez à vos
mails).</p>
</dd>
<dt><b>hard</b></dt>
<dd>
<p>Le client NFS réessaiera infiniment jusqu'à ce
qu'il soit tué. Les opérations reprendront
normalement si le serveur NFS se rétablit ou
redémarre. Le client ne pourra pas être interrompu ou
tué.</p>
</dd>
<dt><b>hard,intr</b></dt>
<dd>
<p>Comme hard, mais Ctrl-C tuera le processus bloqué. Dans
quelques cas, notament un disque /usr/spool/mail monté par
NFS cela ne changera rien car le shell ignore le Ctrl-C quand il
teste si vous avez du mail. Je recommande cette option pour
<b>tous</b> les systèmes de fichiers NFS, y compris le
<em>spool</em> du mail.</p>
</dd>
</dl>
<p>Reprenons l'exemple précédent, votre entrée
fstab est maintenant :</p>
<hr>
<pre>
# device mountpoint fs-type options dumps sfckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...
</pre>
<hr>
<h2><a name="optimizing"></a> <a name="ss4.2">4.2 Optimisation de
NFS</a></h2>
<p>Normalement, si les options rsize et wsize ne sont pas
précisées, NFS écrira et lira par blocs de
4096 ou 8192 octets. Mais certaines combinaisons de noyau Linux et
cartes réseau ne peuvent pas fonctionner avec ces valeurs,
de plus, même si cela marche, cela peut ne pas être
optimal du tout. Il nous faudra donc expérimenter et trouver
les valeurs de rsize et wsize qui fonctionnent et donnent les
transferts les plus rapides. Vous pouvez tester la vitesse obtenue
avec différentes valeurs des options avec des commandes
simples. La commande mount ci-dessus ayant été
exécutée, si vous avez l'accès en
écriture sur le disque vous pouvez tester les performances
en écriture séquentielle :</p>
<hr>
<pre>
time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096
</pre>
<hr>
<p>Ceci crée un fichier de 64 Mo ne contenant que des 0.
Faites le quelques (5-10?) fois et prenez la moyenne des temps.
C'est le temps `elapsed' ou `wall clock' qui est le plus
intéressant. Ensuite vous pouvez tester les performances en
lecture en relisant le fichier :</p>
<hr>
<pre>
time dd if=/mnt/testfile of=/dev/null bs=16k
</pre>
<hr>
<p>faites le quelques fois et prenez la moyenne. Puis
démontez (<code>umount</code>) et remontez
(<code>mount</code>) avec des valeurs plus grandes pour rsize et
wsize. Il vaut mieux prendre des multiples de 1024, et probablement
pas plus grand que 16384 octets, car les gros blocs ralentissent
les accès aléatoires. Immédiatement
après avoir re<code>mount</code>é avec une taille
supèrieure, placez vous (<code>cd</code>) dans le
système de fichiers et faites des trucs comme ls, explorez
un peu pour vérifier que tout est bien normal. Si la valeur
de rsize/wsize est trop grande, les symptômes sont
<em>vraiment</em> bizarres et pas évidents. Un
symptôme typique est une liste de fichiers donnée par
<code>ls</code> incomplète sans aucun message d'erreur. Ou
la lecture de fichier qui échoue mystérieusement et
sans message d'erreur. Après vous être assurés
que les wsize/rsize choisis fonctionnent, vous pouvez faire les
tests de rapidité. Différentes plateformes de serveur
auront peut-être des tailles optimales différentes.
SunOS et Solaris sont réputés pour être
beaucoup plus rapides avec une taille de 4096 octets.</p>
<p>Les noyaux Linux récents (depuis 1.3) font parfois des
lectures anticipées (<em>read ahead</em>) pour des rsizes
supérieurs ou égaux à la taille de page de la
machine. Sur les processeurs Untel la taille de la page est de 4096
octets. La lecture anticipée augmentera
<em>sensiblement</em> les performances en lecture. Sur une machine
Untel on devrait donc choisir un rsize de 4096 si c'est
possible.</p>
<p>Un truc pour augmenter les performances d'écriture de NFS
est d'invalider les écritures synchrones sur le serveur. Les
spécifications de NFS disent que les requêtes
d'écriture de NFS ne doivent pas être
considérées comme terminées avant que les
données ne soient sur un médium non versatile
(normalement le disque). Ceci réduit les performances
à l'écriture, les écritures asynchrones sont
plus rapides. Le nfsd Linux ne fait pas d'écritures
synchrones car l'implémentation du système de
fichiers ne s'y prête pas, mais sur les serveurs non Linux
vous pouvez augmenter les performances de cette façon dans
votre fichier exports :</p>
<hr>
<pre>
/dir -async, access=linuxbox
</pre>
<hr>
<p>ou quelque chose du genre. Référez vous à
la page de manuel exports de la machine concernée. Notez que
ceci augmente les risques de perte de données.</p>
<h2><a name="slow-lines"></a> <a name="s5">5. NFS sur les lignes
à faible débit</a></h2>
<p>Les lignes lentes (à faible débit) comprennent les
modems, RNIS et aussi sans doute les autres connexions longue
distance.</p>
<p>Cette section est basée sur la connaissance des
protocoles utilisés mais pas sur des
expérimentations. Faites moi savoir si vous essayez ceci
;-)</p>
<p>La première chose à retenir est que NFS est un
protocole lent. Il a un grand <em>overhead</em> (sur-coût en
bande passante). Utiliser NFS, c'est presque comme utiliser kermit
pour transférer des fichiers. Il est <em>lent</em>. Presque
tout est plus rapide que NFS. FTP est plus rapide. HTTP est plus
rapide. rcp est plus rapide. ssh est plus rapide.</p>
<p>Vous voulez toujours l'essayer ? Ok.</p>
<p>Par défaut NFS est paramétré pour des
lignes rapides et à faible latence. Si vous utilisez les
paramètres par défaut sur des lignes à grande
latence cela peut provoquer des erreurs, des annulations, des
rétrécissements de fichiers, et des comportements
bizarres.</p>
<p>La première chose à faire est de ne <em>pas</em>
utiliser l'option de montage <code>soft</code>. Les temporisations
retourneront des erreurs au logiciel, qui, dans l'immense
majorité des cas, ne saura pas quoi en faire. C'est une
bonne façon d'avoir des problèmes bizarres. Utilisez
plutôt l'option de montage <code>hard</code>. Quand
<code>hard</code> est actif les temporisations déclenchent
des essais infinis au lieu d'annuler ce que le logiciel
était en train de faire (quoi que ce soit). C'est ce que
vous voulez. Vraiment.</p>
<p>La deuxième chose à faire est d'ajuster les
options de montage <code>timeo</code> et <code>retrans</code>.
Elles sont décrites dans la page de manuel nfs(5), en voici
un extrait (version française) :</p>
<hr>
<pre>
timeo=n La valeur, en dixiemes de secondes, du
delai avant de declencher la premiere
retransmission d'une RPC. La valeur par
defaut est 7/10 de seconde. Apres une pre­
miere expiration, le delai est double et
l'on recommence les retransmissions jusqu'a
ce que le delai atteigne la valeur maximale
de 60 secondes, ou que le nombre maximal de
retransmission soit depasse. Il se produit
alors une erreur d'expiration majeure de
delai. Si le systeme est monte "en dur",
les retransmissions reprendront a nouveau
indefiniment.
On peut ameliorer les performances en aug­
mentant le delai sur un reseau charge, si
le serveur est un peu lent, ou si l'on
traverse plusieurs routeurs ou passerelles.
retrans=n Le nombre d'expirations mineures et de
retransmissions qui doivent se produire
avant de declencher une expiration majeure.
La valeur par defaut est 3 expirations
mineures. Quand une erreur d'expiration
majeure se produit, soit l'operation est
abandonnee, soit un message "server not
responding" est affiche sur la console.
</pre>
<hr>
<p>En d'autres mots : si une réponse n'est pas reçue
avant la temporisation de 0,7 seconde (700 ms), le client NFS
répétera la requête et doublera la
temporisation à 1,4 seconde. Si la réponse n'arrive
pas dans les 1,4 seconde, la requête est
répétée à nouveau et la temporisation
est doublée à 2,8 secondes.</p>
<p>La vitesse de la ligne peut être mesurée avec un
ping ayant vos valeurs de rsize/wsize comme taille de paquet.</p>
<hr>
<pre>
$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms
--- lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms
</pre>
<hr>
<p>Le temps indiqué est celui que le paquet du ping a pris
pour aller et revenir de lugulbanda. 15 ms, c'est assez rapide. Sur
une ligne à 28 800 bps vous pouvez vous attendre à
une valeur de l'ordre de 4000-5000 ms, et si la ligne est
chargée ce temps sera encore plus élevé,
facilement le double. En général, la latence augmente
avec la taille des paquets et la charge de la ligne. Si vous
comptez utiliser FTP et NFS en même temps il faudra mesurer
les temps du ping pendant un transfert FTP et augmenter
<code>timeo</code> en accord avec la latence de votre ligne.</p>
<h2><a name="nfs-security"></a> <a name="s6">6. NFS et la
sécurité</a></h2>
<p>Je ne suis en aucun cas un expert en sécurité
informatique. Mais j'ai traîné dans le secteur et j'ai
un <em>petit</em> conseil pour ceux qui se préoccupent de la
sécurité. Mais attention. Ce n'est pas absolument pas
une liste complète des problèmes liés à
NFS et si vous pensez être en sécurité une fois
que vous avez lu et mis en pratique tout ceci alors j'ai un pilier
de pont (presque neuf) à vous vendre.</p>
<p>Cette section n'a probablement pas d'intérêt si
vous êtes sur un réseau <em>fermé</em>
où vous avez confiance en tous les utilisateurs, et que
personne en qui vous n'avez pas confiance ne peut obtenir un
accès sur les machines du réseau. I.e., il ne devrait
y avoir aucun moyen de se connecter à votre réseau
depuis l'extérieur et il ne devrait être relié
à aucun autre réseau où vous n'avez pas
confiance en tous les utilisateurs et en sa sécurité.
Vous pensez que je suis parano ? Pas du tout. C'est un conseil de
sécurité <em>de base</em>. Et rappelez-vous que c'est
juste le commencement. Un site <em>sûr</em> nécessite
un administrateur consciencieux et bien informé qui sait
où trouver l'information sur les problèmes de
sécurité existants ou potentiels.</p>
<p>Un problème de base de NFS est que le client, si on ne
lui demande pas le contraire, fera confiance au serveur NFS et vice
versa. Ça peut être mauvais. Cela signifie que si le
compte root du serveur est cassé (<em>broken into</em>) il
peut être très facile de casser le compte root du
client. Et vice versa. Il y a quelques moyens de gérer ce
problème sur lesquels nous reviendrons.</p>
<p>Les documents consultatifs (<em>advisories</em>) du CERT sur NFS
sont une bonne source d'information, la plupart des
problèmes (et des solutions) évoquées
ci-dessous sont traités dans ces documents. Voyez <a href=
"ftp://ftp.cert.orf/01-README">ftp.cert.org:/01-README</a> pour une
liste à jour. En voici quelques-uns liés à NFS
(il n'y a pas à ma connaissance de version française)
:</p>
<hr>
<pre>
CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91
Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network
File System (NFS) and the fsirand program. These vulnerabilities
affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures.
Patches are available for SunOS 4.1.1. An initial patch for SunOS
4.1 NFS is also available. Sun will be providing complete patches
for SunOS 4.1 and SunOS 4.0.3 at a later date.
CA-94:15.NFS.Vulnerabilities 12/19/94
This advisory describes security measures to guard against several
vulnerabilities in the Network File System (NFS). The advisory was
prompted by an increase in root compromises by intruders using tools
to exploit the vulnerabilities.
CA-96.08.pcnfsd 04/18/96
This advisory describes a vulnerability in the pcnfsd program (also
known as rpc.pcnfsd). A patch is included.
</pre>
<hr>
<h2><a name="ss6.1">6.1 Sécurité du client</a></h2>
<p>Du côté client il y a quelques options de mount qui
permettent de ne pas faire trop confiance au serveur. L'option
<code>nosuid</code> interdit le démarrage de programmes suid
depuis le système de fichiers NFS. C'est une option à
utiliser systématiquement, car elle empêche le root du
serveur de créer un fichier suid sur le système de
fichiers NFS, puis de se loger dans le client en utilisateur et de
lancer le programme suid pour devenir root sur le client. Il est
aussi possible d'interdire l'exécution des fichiers du
système de fichiers NFS avec l'option <code>noexec</code>.
Mais ceci est beaucoup moins utile que <code>nosuid</code> car le
système de fichiers contiendra très probablement au
moins <em>quelques</em> scripts ou programmes à
exécuter. Ces options se rentrent dans la colonne d'options,
avec <code>wsize</code> et <code>rsize</code>,
séparées par des virgules.</p>
<h2><a name="ss6.2">6.2 Sécurité du serveur :
nfsd</a></h2>
<p>Du côté serveur on peut ne pas faire confiance au
root du client, avec l'option <code>root_squash</code> (rembarrage
du root :-) dans le fichier exports :</p>
<hr>
<pre>
/mn/eris/local apollon(rw, root_squash)
</pre>
<hr>
<p>Dans ce cas, si un utilisateur du client avec l'UID 0 essaye
d'accéder (en lecture, écriture ou effacement) au
système de fichiers, le serveur remplace l'UID par celui de
l'utilisateur `nobody' du serveur. Ceci signifie que l'utilisateur
root du client ne peut accéder/modifier les fichiers du
serveur que seul le root du serveur peut accéder/modifier.
C'est bien, et vous aurez probablement à utiliser cette
option sur tous les systèmes de fichiers que vous exportez.
J'en entends un qui me dit : ``Mais l'utilisateur root du client
peut toujours utiliser 'su' pour devenir n'importe qui et
accéder à ses fichiers !'' Et là je
réponds : ``Oui, c'est comme ça, c'est Unix''. Ceci a
une conséquence importante : tous les fichiers et binaires
importants devraient appartenir à <code>root</code>, et pas
<code>bin</code> ou un compte autre que root, car le seul compte
auquel le root du client ne peut pas accéder est le compte
root du serveur. Plusieurs autres options permettant de ne pas
faire confiance à qui ne vous plait pas sont
énumérées dans la page de manuel nfsd. Il y a
aussi des options pour rembarrer (<em>to squash</em>) des
intervalles d'UID ou GID.</p>
<p>Il est important aussi de s'assurer que nfsd vérifie que
toutes les requêtes viennent d'un port
privilégié. S'il accepte les requêtes de
n'importe quel port du client, un utilisateur quelconque peut
exécuter un programme qu'il est facile de se procurer sur
l'Internet. Il parle le protocole NFS et pourra prétendre
être n'importe qui et être cru. Ça fait peur
hein ? Le nfsd Linux effectue cette vérification par
défaut, sur d'autres systèmes d'exploitation il faut
la valider. Ça devrait être décrit dans les
pages du manuel de ce système.</p>
<p>Autre chose. N'exportez jamais un système de fichiers
vers `localhost' ou 127.0.0.1. Croyez-moi.</p>
<h2><a name="ss6.3">6.3 Sécurité du serveur : le
portmapper</a></h2>
<p>Le portmapper de base, en combinaison avec nfsd présente
un problème de conception qui rend possible de
récupérer les fichiers d'un serveur NFS sans avoir
aucun privilège. Heureusement le portmapper utilisé
par la plupart des distributions Linux est relativement sûr
vis à vis de cette attaque, et peut être
sécurisé en configurant les listes d'accès au
moyen de deux fichiers.</p>
<p>Toutes les distributions de Linux ne sont pas égales.
Certaines apparemment à jour n'incluent <em>pas</em> un
portmapper sur, même aujourd'hui, alors que le
problème est connu depuis plusieurs années. Au moins
une distribution contient même la page de manuel pour un
portmapper sûr alors que le portmapper effectivement
installé n'est <em>pas</em> sûr. Pour
déterminer simplement si votre portmapper est le bon ou pas,
lancez strings(1) et voyez s'il lit les fichiers appropriés
<code>/etc/hosts.deny</code> et <code>/etc/hosts.allow</code>. Si
votre portmapper est <code>/usr/sbin/portmap</code> exécutez
la commande <code>strings /usr/sbin/portmap | grep hosts</code>.
Sur ma machine cela donne :</p>
<hr>
<pre>
/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27
</pre>
<hr>
<p>Tout d'abord, éditons <code>/etc/hosts.deny</code>. Il
devrait contenir la ligne :</p>
<hr>
<pre>
portmap: ALL
</pre>
<hr>
<p>qui refusera l'accès à <em>quiconque</em>.
Maintenant qu'il est fermé, lancez <code>rpcinfo -p</code>
pour vérifier qu'il lit et se conforme au contenu du
fichier. rpcinfo ne devrait rien renvoyer, ou peut être un
message d'erreur. Il ne devrait <em>pas</em> y avoir besoin de
relancer le portmapper.</p>
<p>Fermer le portmapper à tous le monde est peut être
un peu excessif, nous ré-ouvrons donc quelque peu
l'accès en éditant le fichier
<code>/etc/hosts.allow</code>. Mais il faut d'abord savoir ce qu'on
va y mettre. À la base, il devrait contenir les noms de
toutes les machines qui doivent avoir accès à votre
portmapper. Sur le système Linux moyen il y a très
peu de machines qui ont une bonne raison de demander cet
accès. Le portmapper administre nfsd, mountd, ypbind/ypserv,
pcnfsd et les services ``en r'' comme ruptime et rusers. Parmis
ceux-ci, seuls nfsd, mountd, ypbind/ypserv et peut-être
pcnfsd ont de l'importance. Toutes les machines qui ont besoin
d'accéder à ces services sur votre machine devraient
y être autorisées. Disons que votre machine est
129.240.223.254 et que tout ce qui vit sur le sous réseau
129.240.223.0 doit pouvoir y accéder (si ceci n'est pas
clair pour vous, voyez le HOWTO réseau). On écrit
:</p>
<hr>
<pre>
portmap: 129.240.223.0/255.255.255.0
</pre>
<hr>
<p>dans <code>hosts.allow</code>. C'est l'adresse de réseau
que vous donnez aussi à la commande <code>route</code> et le
masque de réseau que vous donnez à
<code>ifconfig</code>. Pour le périférique
<code>eth0</code> sur cette machine <code>ifconfig</code> devrait
donner :</p>
<hr>
<pre>
...
eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:360315 errors:0 dropped:0 overruns:0
TX packets:179274 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
...
</pre>
<hr>
<p>et <code>netstat -rn</code> devrait donner :</p>
<hr>
<pre>
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
...
</pre>
<hr>
<p>(Adresse réseau dans la première colonne)</p>
<p>Les fichiers <code>hosts.deny</code> et <code>hosts.allow</code>
sont décrits dans les pages de manuel de mêmes
noms.</p>
<p><b>IMPORTANT</b> : ne <em>rien</em> mettre d'autre que des
adresses IP (numériques) dans les lignes portmap de ces
fichiers. Les <em>host name lookup</em> (recherche d'adresse IP
(numérique) à partir de l'adresse
alphanumérique ex. ftp.lip6.fr donne 132.227.77.2) peuvent
indirectement déclencher une activité portmap qui
déclenchera un <em>host name lookup</em> qui
déclenchera...</p>
<p>Ceci fait, votre serveur devrait être un peu plus solide.
Le dernier problème (mais oui !) est que quelqu'un casse le
compte root (ou boute MS-DOS) sur une machine de confiance et
utilise ce privilège pour envoyer des requêtes depuis
un port sûr en se faisant passer pour n'importe quel
utilisateur.</p>
<h2><a name="ss6.4">6.4 NFS et les coupent-feu (firewalls)</a></h2>
<p>C'est une très bonne idée de bloquer les ports NFS
et portmap dans votre routeur ou firewall. nfsd utilise le port
2049, que ce soit avec tcp ou udp. Le portmapper est au port 749
(tcp et udp) et mountd aux port 745 et 747 (tcp et udp).
Vérifiez les ports avec la commande <code>rpcinfo
-p</code>.</p>
<p>Si au contraire vous voulez que NFS traverse un firewall, il
existe des options sur les nfsd et mountd récents pour leur
spécifier le port à utiliser. Vous pouvez donc
choisir un port qui ne soit pas bloqué par le firewall.</p>
<h2><a name="ss6.5">6.5 Résumé</a></h2>
<p>Si vous configurez correctement votre installation
portmapper/NFS avec hosts.allow/deny, root_squash, nosuid et les
ports privilégiés, vous évitez beaucoup des
bogues connues de NFS et pouvez presque vous sentir en
sécurité au moins pour <em>ça</em>. Mais de
toutes façons : quand un intrus obtient l'accès
à votre réseau, il/elle peut faire apparaître
des commandes bizarres dans votre .forward ou lire votre mail quand
<code>/home</code> ou <code>/var/spool/mail</code> sont
exportés. Pour la même raison, vous ne devriez jamais
accéder à votre clé privée PGP par NFS.
Ou au moins vous devez savoir quel est le risque. Et maintenant
vous savez un peu.</p>
<p>NFS et le portmapper constituent un système complexe et
il n'est donc pas totalement exclu que de nouvelles bogues soient
découvertes, soit dans la conception soit dans
l'implémentation que nous utilisons. Il pourrait même
y avoir des défauts de sécurité connus, que
quelqu'un utilise. Mais c'est la vie. Pour vous tenir au courant,
vous devriez au moins lire les forums comp.os.linux.announce et
comp.security.announce comme minimum absolu (en français,
consultez fr.comp.os.linux.annonces).</p>
<h2><a name="s7">7. ``Checklist'' mount</a></h2>
<p>Cette section est basée sur la <i>mount checklist</i>
(liste des problèmes liés à
<code>mount</code>) de IBM Corp. Je les remercie de m'autoriser
à l'utiliser dans ce HOWTO. Si vous avez un problème
en montant un système de fichiers NFS, consultez cette liste
avant de poster votre problème sur les niouzes. Chaque point
décrit un type de problème et sa solution.</p>
<ol>
<li>Mount répète <code>RPC: Program not
registered</code>
<p>Le portmapper tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p>mountd tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p>nfsd tourne ?</p>
<p><b>Solution :</b> lancez-le.</p>
<p><code>/etc/hosts.deny</code> empêche le portmapper de
répondre ?</p>
<p><b>Solution :</b> vous pouvez enlever la règle en
question dans <code>hosts.deny</code> ou en ajouter une dans
<code>hosts.allow</code> de façon que le portmapper soit
autorisé à vous parler.</p>
</li>
<li>Système de fichier non exporté, ou non
exporté au client en question.
<p><b>Solution :</b> exportez le [Ndt : merci IBM !]</p>
</li>
<li>La résolution de noms ne s'accorde pas avec la liste des
exports.
<p>e.g.: la liste des exports dit d'exporter vers
<code>johnmad</code> mais le nom de <code>johnmad</code> est
résolu en <code>johnmad.austin.ibm.com</code>. La permission
de monter est refusée.</p>
<p><b>Solution :</b> exportez vers les deux formes du nom.</p>
<p>Cela peut aussi arriver si le serveur a deux interfaces avec des
noms différents et que les exports n'en spécifient
qu'un.</p>
<p><b>Solution :</b> exportez les deux interfaces.</p>
<p>Cela peut aussi se produire si le serveur ne peut pas faire un
lookuphostbyname ou lookuphostbyaddr (ce sont des fonctions de
bibliothèque) sur le client. Assurez-vous que le client peut
faire <code>host <name></code>; <code>host
<ip_addr></code>; et que les deux donnent la même
machine.</p>
<p><b>Solution :</b> mettez de l'ordre dans la résolution de
noms.</p>
</li>
<li>Le système de fichiers a été monté
après que NFS soit lancé (sur ce serveur). Dans ce
cas le serveur exporte le point de montage sous-jacent, pas le
système de fichiers.
<p><b>Solution :</b> éteignez nfsd et relancez le.</p>
<p><b>Note :</b> les clients qui avaient monté le point de
montage sous-jacent auront des problèmes pour y
accéder après le redémarrage.</p>
</li>
<li>La date est très décalée sur une ou sur
les deux machines (cela peut mettre la pagaille pour make)
<p><b>Solution :</b> réglez correctement la date.</p>
<p>L'auteur du HOWTO recommande d'utiliser NTP pour synchroniser
les horloges. Vu qu'il y a des restrictions à l'exportation
(au sens commercial !) de NTP aux É.U., vous devez vous
procurer NTP pour Debian, Redhat ou Slakware depuis
<code>ftp://ftp.hacktic.nl/pub/replay/pub/linux</code> ou un
miroir.</p>
</li>
<li>Le serveur ne peut pas utiliser un mount d'un utilisateur qui
est dans plus de 8 groupes. <b>Solution :</b> diminuez le nombre de
groupes auxquels l'utilisateur appartient ou montez depuis un autre
utilisateur.</li>
</ol>
<h2><a name="s8">8. FAQ</a></h2>
<p>Voici la section FAQ. Elle est en partie basée sur une
vieille FAQ NFS écrite par Alan Cox.</p>
<p>Si vous avez un problème pour monter un système de
fichier, voyez si votre problème est décrit dans la
section ``Checklist mount''.</p>
<ol>
<li>J'obtiens un tas d'erreurs ``stale nfs handle'' quand j'utilise
Linux comme serveur NFS.
<p>Cela est dû à une bogue dans quelques vieilles
versions de nfsd. Elle est corrigée à partir de
nfs-server2.2beta16.</p>
</li>
<li>Quand j'essaye de monter le système de fichiers
j'obtiens
<blockquote>
<pre>
<code> can't register with portmap: system error on send
</code>
</pre></blockquote>
<p>Vous utilisez probablement un système Caldera. Il y a une
bogue dans les scripts rc. Contactez Caldera pour obtenir la
solution.</p>
</li>
<li>Pourquoi ne puis-je pas exécuter un fichier après
l'avoir copié sur le serveur NFS ?
<p>La raison est que nfsd cache les manipulations de fichiers pour
des raisons de performances (rappelons qu'il fonctionne dans
l'espace utilisateur). Ainsi, après une écriture le
fichier peut ne pas être fermé tout de suite, et tant
qu'il est ouvert le noyau ne vous autorisera pas à
l'exécuter. Les nfsd plus récents que le printemps 95
[Ndt : hum...] ferment les fichiers ouverts après quelques
secondes, les plus vieux pouvaient ne pas les relâcher avant
plusieurs jours...</p>
</li>
<li>Mes fichiers NFS sont tous en lecture seule.
<p>Le serveur NFS Linux est par défaut en lecture seule.
Voyez les sections ``Mountd et nfsd'' et ``Exporter des
systèmes de fichier'' dans ce HOWTO et référez
vous aux pages de manuel ``exports'' et ``nfsd''. Vous devrez
modifier <code>/etc/exports</code>.</p>
</li>
<li>Je monte depuis un serveur NFS Linux, <code>ls</code> marche et
pourtant je ne peux pas lire ou écrire de fichiers.
<p>Sur les anciennes versions de Linux il faut monter un serveur
NFS avec <code>rsize=1024, wsize=1024</code>.</p>
</li>
<li>Je monte depuis un serveur NFS Linux avec une taille de bloc
comprise entre 3500 et 4000 et Linux crashe
régulièrement.
<p>Bah alors ne le faites pas. Cela ne se produit pas avec les
noyaux 2.0 et 2.2 ni, autant que je sache avec les 1.2.</p>
</li>
<li>Est-ce que Linux peut utiliser NFS sur TCP ?
<p>Non, pas pour le moment.</p>
</li>
<li>J'ai des tonnes d'erreurs bizarres en essayant de monter depuis
un serveur Linux.
<p>Assurez-vous que vos utilisateurs sont dans 8 groupes au
maximum. C'est une limitation des vieux serveurs.</p>
</li>
<li>Quand je redémarre ma machine elle se bloque parfois en
essayant de démonter un serveur NFS bloqué
(<em>hung</em>).
<p>Ne démontez <b>pas</b> les serveurs NFS en
redémarrant ou arrêtant la machine, ça ne
créera pas de problèmes si vous ne le faites pas. La
commande est <code>umount -avt nonfs</code>.</p>
</li>
<li>Les clients NFS Linux sont très lents quand ils
écrivent sur des systèmes Sun ou BSD.
<p>Normalement les écritures NFS sont synchrones (vous
pouvez le désactiver si vous ne craignez pas de perdre des
données). Les noyaux dérivés de BSD ont
tendance à ne pas savoir travailler avec des petits blocs.
Ainsi quand vous écrivez 4K de données depuis un
client Linux dans des paquets de 1K, BSD fait ceci :</p>
<blockquote>
<pre>
<code> lit une page de 4K
traite 1K
écrit 4K sur le disque
lit une page de 4K
traite 1K
écrit 4K sur le disque
...
</code>
</pre></blockquote>
</li>
<li>Quand je connecte de nombreux clients à un serveur NFS
Linux, la performance diminue soudainement.
<p>Le protocole NFS utilise les paquets UDP fragmentés. Le
noyau ne conserve qu'un nombre limité de fragments de
paquets incomplets avant de commencer à jeter des paquets.
En 2.2, ce paramètre est réglable à
l'exécution au moyen du système de fichier /proc :
<code>/proc/sys/net/ipv4/ipfrag_high_tresh</code> et
<code>ipfrag_low_tresh</code>. En 2.0 ce sont des constantes
définies à la compilation dans
<code>.../linux/net/ipv4/ip_fragment.c</code>,
<code>IPFRAG_HIGH_TRESH</code> et <code>IPFRAG_LOW_THRESH</code>.
La signification des ces valeurs est que quand la mémoire
consommée par les fragments UDP non
réassemblés atteint ``ipfrag_high_thresh'' (en
octets, 256K par défaut en 2.2.3 et 2.0.36) elle est
ramenée à ``ipfrag_low_tresh'' d'un coup, en jetant
des fragments. Ainsi, si la borne supérieure (high_tresh)
est atteinte, la performance de votre serveur diminue
drastiquement.</p>
<p>256K est suffisant pour 30 clients. Si vous en avez 60, doublez
la valeur. Et doublez aussi la borne inférieure
(low_tresh).</p>
</li>
<li>J'utilise Linux 2.2 (ou suivant) avec knfsd et ma machine AIX,
IRIX, Solaris, DEC-Unix, ... n'arrive pas à monter de
volume.
<p>knfsd annonce qu'il implémente NFS version 3, alors que
ce n'est pas vrai. Utilisez l'option qui permet de stopper ces
annonces, ou mettez <code>"vers=2"</code> dans la liste d'options
de montage de votre client.</p>
</li>
<li>Ma machine AIX 4 n'arrive pas à monter depuis mon
serveur NFS Linux. Elle dit quelque chose du genre :
<blockquote>
<pre>
<code> mount: 1831-011 access denied for server:/dir
mount: 1831-008 giving up on:
server:/dir
The file access permissions do not allow the specified action.
</code>
</pre></blockquote>
<p>AIX 4.2 utilise des ports réservés (<1024) pour
NFS. AIX 4.2.1 et 4.3 peuvent utiliser d'autres ports, et essaient
de monter par NFS3, NFS/TCP et finalement NFS/UDP.</p>
<p>Ajouter</p>
<hr>
<pre>
nfso -o nfs_use_reserved_ports=1
</pre>
<hr>
<p>à la fin de <code>rc.tcpip</code> la forcera à
utiliser les ports réservés (truc fourni par Brian
Gorka).</p>
</li>
</ol>
<h2><a name="s9">9. Exporter un système de fichiers</a></h2>
<p>Bien sur, la façon d'exporter les systèmes de
fichiers par NFS n'est pas toujours la même sur toutes les
plate-formes. Linux et Solaris 2 sont les plus déviants.
Cette section liste de manière superficielle la façon
de procéder sur la plupart des systèmes. Si votre
système n'est pas traité ici, cherchez dans vos pages
de manuel. Les mot-clés sont : nfsd, system administration
tool, rc scripts, boot scripts, boot sequence, /etc/exports,
exportfs. J'utiliserai le même exemple tout au long de cette
section : comment exporter /mn/eris/local vers apollon en
lecture/écriture.</p>
<h2><a name="ss9.1">9.1 IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4
(Solaris 1), AIX</a></h2>
<p>Ces systèmes utilisent le format export traditionnel de
Sun. Dans <code>/etc/exports</code>, écrivez :</p>
<hr>
<pre>
/mn/eris/local -rw=apollon
</pre>
<hr>
<p>La documentation complète se trouve dans la page de
manuel <code>exports</code>. Après avoir édité
le fichier, lancez <code>exportfs -av</code> pour exporter les
systèmes de fichiers.</p>
<p>La rigueur de la syntaxe demandée par exportfs varie. Sur
certains systèmes vous verrez que la ligne
précédente peut être :</p>
<hr>
<pre>
/mn/eris/local apollon
</pre>
<hr>
<p>ou même quelque chose de
dégénéré comme :</p>
<hr>
<pre>
/mn/eris/local rw=apollon
</pre>
<hr>
<p>Je recommande d'utiliser la syntaxe stricte. Il se peut que la
prochaine version de <code>exportfs</code> soit plus exigeante vis
à vis de la syntaxe et ne fonctionne plus.</p>
<h2><a name="ss9.2">9.2 Solaris 2</a></h2>
<p>Sun ont complètement réinventé la roue
quand ils ont fait Solaris 2, et donc c'est complètement
différent des autres systèmes. Il faut éditer
le fichier <code>/etc/dfs/dfstab</code> et y placer les commandes
de partage (<em>share</em>) documentées dans la page de
manuel <code>share(1M)</code>, comme ceci :</p>
<hr>
<pre>
share -o rw=apollon -d "Eris Local" /mn/eris/local
</pre>
<hr>
<p>Lancez ensuite le programme <code>shareall</code> pour exporter
les systèmes de fichiers.</p>
<h2><a name="linuxtwotwo"></a> <a name="s10">10. NFS sous Linux
2.2</a></h2>
<p>Au moment où j'écris, la version courante du noyau
est 2.2.12 et utiliser NFS peut être assez pénible. Ou
pas. J'ignore ce qu'il en sera pour Linux 2.4.</p>
<p>La grosse nouveauté dans Linux 2.2 c'est le support d'un
serveur nfs dans le noyau, appelé knfsd 2.2. Ce type
d'implémentation a des avantages, principalement la
rapidité, une machine Linux 2.2 avec knfsd est un serveur
NFS respectable. Vous pouvez cependant toujours utiliser l'ancien
nfsd avec Linux 2.2, et cela présente quelques avantages
aussi, dont la simplicité.</p>
<p>Si vous utilisez un paquetage noyau source ou binaire
fabriqué par quelqu'un comme RedHat (6.0 et suivantes), SuSE
(6.1 et suivantes il me semble) ou un autre intégrateur de
système professionnel ils auront probablement
intégré complètement ``knfsd'' et vous n'avez
pas de soucis à vous faire, cela marchera. Pour l'essentiel.
Jusqu'à ce que vous vouliez compiler un noyau vous
même. Si vous utilisez un noyau 2.2 standard (au moins
jusqu'à 2.2.12) knfsd ne fonctionnera pas.</p>
<p>Pour le faire fonctionner vous même il vous faut le
paquetage knfsd de H.J. Lu. C'est un ensemble de patchs avec les
utilitaires requis pour 2.2 que Lu maintient
bénévolement. Récupérez le depuis votre
miroir de noyau local, le site maître est <a href=
"ftp://ftp.kernel.org/pub/linux/devel/gcc/">ftp.kernel.org:/pub/linux/devel/gcc/</a>.
<b>Ce n'est pas destiné au grand public</b>. Si vous trouvez
que c'est trop compliqué, n'insistez pas et attentez qu'un
paquetage noyau soit disponible auprès de votre
intégrateur (Redhat, SuSE...).</p>
<p>Ne m'envoyez pas de question à ce sujet, je ne peux pas
vous aider, je n'ai aucun serveur basé sur knfsd qui tourne.
Si vous trouvez des erreurs ou omissions dans la documentation,
écrivez-moi et je corrigerai ce HOWTO.</p>
<p>Toujours là ? Ok. H.J. Lu annonce les nouvelles versions
de son paquetage sur la liste de diffusion linux-kernel, où
il passe d'autres choses liées à NFS dans Linux 2.2.
Lisez-la.</p>
<h2><a name="ss10.1">10.1 Le client</a></h2>
<p>Le client est presque simple. Afin que les verrous
(<em>locks</em>) marchent correctement il faut que
<code>statd</code> (du paquetage knfsd) soit compilé,
installé et lancé depuis vos scripts de
démarrage. Statd a besoin d'un répertoire
appelé <code>/var/lib/nfs</code> qu'il vous faudra
créer avant de le lancer (sans quoi il se termine
immédiatement sans message d'erreur).</p>
<p>Une fois que statd tourne vous pouvez utiliser le programme
<code>testlk</code> (dans <code>tools/locktest</code>) pour tester
si un verrou sur un fichier d'un volume monté par NFS
fonctionne. Ça devrait. S'il affiche <em>No locks
available</em>, statd ne fonctionne pas.</p>
<p>En fait, vous pouvez aussi vous passer des verrous (ce que je ne
recommande pas) en mettant <code>"nolock"</code> dans la liste des
options de montage.</p>
<p>Autant que je sache, c'est tout ce qu'il faut pour faire
fonctionner correctement le client.</p>
<p>Ah, si vous avez un serveur NFS Alpha ou Sparc vous verrez que
le client nfs de Linux 2.2 est vraiment de la merde. Les
débits sont extrêmement faibles, bien pire qu'avec
Linux 2.0. Bien sur on peut corriger le problème. Les noyaux
2.2 d'Alan Cox (un petit peu plus expérimentaux que ceux de
Linus) incluent un patch pour améliorer la performance du
client 2.2 avec un serveur Alpha ou Sparc. Si vous voulez utiliser
les noyaux d'Alan Cox, vous devriez lire la liste de diffusion
linux-kernel, et si c'est le cas vous savez où les trouver.
Le site de référence est <a href=
"http://www.uio.no/~trondmy/src/">http://www.uio.no/~trondmy/src/</a>,
au cas où vous voudriez essayer de l'appliquer à un
noyau 2.2 standard. Ce patch ne sera probablement pas
intégré dans Linux 2.4, car il demande trop de
changements dans le noyau pour être accepté dans le
cycle de développement actuel. Attendez Linux 2.5.</p>
<p><code>trondmy</code> propose des patchs pour utiliser NFS
version 3 avec Linux, et qui permettent aussi d'utiliser TCP comme
mécanisme de transport au lieu d'UDP. NFSv3 est très
bien pour des réseaux grande distance ou avec des taux de
pertes non nuls, ou des temps de latence élevés.</p>
<p>Si vous utilisez ces patchs, il vous faut lire linux-kernel, car
de sales bugs, qui mangent vos fichiers, sont parfois
découverts. Alors <b>soyez prudent</b>.</p>
<h2><a name="ss10.2">10.2 Le serveur</a></h2>
<p>Le serveur NFS de Linux 2.2 et suivants est appelé
<code>"knfsd"</code>. Il est difficile à configurer. Il
faudra vous débrouiller tout seul ou utiliser ce que SuSE,
RedHat et autres fournissent dans leurs paquetages 2.2.
Désolé, mais vous pouvez toujours utiliser l'ancien
nfsd. Il est lent mais facile à installer.</p>
<h2><a name="s11">11. Serveur NFS sur une disquette</a></h2>
<p>Cette section a été écrite par Ron Peters,
<a href="mailto:rpeters@hevanet.com">rpeters@hevanet.com</a>. Elle
explique comment installer un serveur NFS en démarrant
depuis une disquette. L'objectif initial était de partager
par NFS un cédérom d'une autre machine pour installer
Linux sur une machine sans lecteur de cédérom.</p>
<h2><a name="ss11.1">11.1 Introduction</a></h2>
<p>Ce document a pour but d'aider ceux qui auront le même
problème que moi récemment. J'installais un serveur
Linux sur une machine sans lecteur de cédérom et sans
moyen d'en installer un, à part peut être un SCSI
externe. Ce genre de situations sera sans doute de plus en plus
rare et ce document perdra donc de son intérêt, mais
j'aurais bien aimé l'avoir quand j'essayais d'installer ma
machine.</p>
<p>Vu que la machine n'avait pas de lecteur de
cédérom, j'ai pensé installer un serveur NFS
pour Win95 afin de partager le lecteur de cédérom
juste le temps d'installer ma machine et de la mettre sur le
réseau. Je n'ai trouvé que deux produits (je ne
citerai pas les noms mais l'un est un freeware et l'autre avait une
licence limitée à 14 jours), l'un ne marcha pas
``clés en main'' et l'autre n'était pas capable de
gérer les conventions de nommage Linux suffisamment bien
pour mener à bien l'installation.</p>
<p>J'ai donc décidé d'essayer de redémarrer ma
machine Win95 sous Linux avec les disquettes boot/root et
d'utiliser une disquette supplémentaire pour installer un
serveur NFS.</p>
<p>Cela a été remarquablement simple, la
procédure est en fait probablement plus simple que de lire
cette introduction. Cependant, je pense qu'il est
intéressant de rassembler les information nécessaires
dans ce document.</p>
<h2><a name="ss11.2">11.2 Attentes</a></h2>
<p>J'ai utilisé les disquettes boot/root fournies dans une
des distributions de Slakware (InfoMagic developpers
distributions). Le noyau utilisé sur les disquettes
était un 2.0.34, et les programmes du serveur NFS venaient
d'un serveur pour 2.0.30. J'ai toujours utilisé la
méthode d'installation Slakware, non pas qu'elle soit plus
facile ou meilleure ou pire, mais simplement qu'elle m'est
familière et que je n'ai jamais pris le temps d'apprendre
à en utiliser une autre.</p>
<p>Je ne pense pas qu'il puisse y avoir beaucoup de
problèmes liés à la version du système.
Je recommanderais simplement d'utiliser un système
relativement récent, ce qui devrait être le cas si
vous utilisez les disquettes boot/root de la distribution à
installer.</p>
<h2><a name="ss11.3">11.3 Matériel
nécessaire</a></h2>
<ul>
<li>Une machine et une disquette de boot supportant le
réseau. La machine devant jouer le rôle du serveur NFS
doit avoir une carte réseau reconnue pendant le
démarrage. Pour plus d'informations, voir le HOWTO sur le
réseau (NET4-HOWTO).</li>
<li>Une deuxième disquette contenant rpc.portmap, rpc.mountd
et rpc.nfsd. Vous pouvez trouver facilement ces fichiers par un
ftpsearch sur le ouèbe.</li>
<li>Un cd (par exemple) Slakware (ou autre).</li>
</ul>
<h2><a name="ss11.4">11.4 Configuration du serveur</a></h2>
<h3>Démarrer le serveur NFS temporaire</h3>
<p>Démarrez la machine qui sera serveur NFS depuis la
disquette de démarrage et assurez-vous que la carte
réseau est reconnue, de même que le lecteur de
cédérom. Dans la suite je suppose que la carte
réseau en question est eth0.</p>
<h3>Monter la disquette et le cédérom</h3>
<p>Une fois que le système est démarré, vous
n'avez plus besoin des disquette boot/root, le système
étant complètement installé en disque
mémoire. Remplacez la disquette root par la disquette
supplémentaire, et montez la :</p>
<p><code>mount /dev/fd0 /floppy</code></p>
<p>Ceci fonctionne pour une disquette avec un système de
fichiers ext2. J'imagine que la disquette pourrait utiliser un
système de fichiers MSDOS mais je n'ai pas essayé. Je
suppose que cela serait plus simple que de faire une image disque.
Dans ce cas, il faudrait utiliser <code>mount -t msdos
...etc</code>.</p>
<p>Montez le cédérom :</p>
<p><code>mount -t iso9660 /dev/hdc /cdrom</code></p>
<p>J'ai utilisé les périphériques disquette et
cédérom, on peut en utiliser d'autres selon ce que
l'on veut faire. Les points de montage /floppy et /cdrom doivent
exister sur l'image de la disquette root. Si ce n'est pas le cas,
créez-les, ou bien vous pouvez utiliser n'importe quels
autres points de montage.</p>
<h3>Configurer le réseau sur le serveur provisoire</h3>
<p>Il faut maintenant configurer le serveur NFS et le
réseau. Il n'y a que quelques commandes à lancer, et
quelques informations qu'il vous faudra rassembler auparavant (je
donne ici des valeurs d'exemple) :</p>
<p>IPADDR:172.16.5.100 #L'adresse du serveur temporaire.</p>
<p>NETMASK:255.255.255.0 #Le masque de réseau (netmask).</p>
<p>BROADCAST:172.16.5.255 #L'adresse de diffusion sur le
réseau</p>
<p>ETHNETWORK:172.16.5.0 #L'adresse réseau</p>
<p>GATEWAY:172.16.5.251 #Nécessaire seulement si vous avez
une passerelle. Si c'est le cas, vous le savez. La plupart des
réseau ``à la maison'' n'en ont pas.</p>
<p>Les commandes pour se connecter au réseau (utiliser les
valeurs données ci-dessus) :</p>
<p><code>ifconfig eth0 inet IPADDR arp netmask NETMASK broadcast
BROADCAST</code></p>
<p><code>route add -net ETHNETWORK netmask NETMASK eth0</code></p>
<p>Celle-ci uniquement si vous avez une passerelle et que vous
devrez la traverser :</p>
<p><code>route add default gw GATEWAY netmask 0.0.0.0
eth0</code></p>
<p>Si tout va bien, vous êtes maintenant sur le réseau
et devriez pouvoir faire des <code>ping</code> sur les autres
machines.</p>
<h3>Configurer le volume NFS</h3>
<p>Choisissez le répertoire à partager. Dans mon
exemple, c'était <code>/cdrom/slakware</code>. Placez-le
dans le fichier <code>/etc/exports</code> :</p>
<p><code>echo "/cdrom/slakware" > /etc/exports</code></p>
<h2><a name="ss11.5">11.5 Lancer le serveur NFS</a></h2>
<p>Allez dans <code>/floppy/usr/bin</code> et lancez :</p>
<p><code>./rpc.portmap</code></p>
<p><code>./rpc.mountd</code></p>
<p><code>./rpc.nfsd</code></p>
<h3>Prêt, commencez l'installation</h3>
<p>Normalement, le répertoire <code>/cdrom/slakware</code>
est maintenant partageable. Démarrez votre machine (celle
à installer) depuis les disquettes boot/root (j'ai
utilisé les mêmes qui ont servi à
démarrer le serveur) et commencez l'installation.</p>
<p>Quand il faut choisir le média source à utiliser,
choisissez ``serveur NFS''. Il vous demandera l'adresse IP du
serveur, qui est celle que vous avez appelé IPADDR pour le
serveur. Il vous faut aussi donner le répertoire à
monter, qui est celui que vous avez indiqué dans le fichier
<code>/etc/exports</code> du serveur.</p>
<p>Le volume NFS devrait maintenant être monté,
surveillez l'apparition de messages d'erreur. Si tout va bien,
continuez l'installation.</p>
<h2><a name="ss11.6">11.6 Problèmes</a></h2>
<h3>Rien ici pour l'instant</h3>
<p>Je n'ai rien à dire à ce sujet pour le moment.
Peut être si des gens utilisent cette procédure, on
aura des choses à ajouter.</p>
<h2><a name="ss11.7">11.7 À faire</a></h2>
<h3>Disquette DOS</h3>
<p>Voir si la disquette supplémentaire peut être au
format DOS.</p>
<h3>Commandes RPC</h3>
<p>Vérifiez l'ordre dans lequel lancer les commandes rpc.*
et si toutes sont nécessaires.</p>
<h2><a name="s12">12. PC-NFS</a></h2>
<p>Vous ne voulez pas utiliser PC-NFS, mais plutôt samba.</p>
<p>Samba est bien meilleur que PC-NFS, il fonctionne avec
``Windows3 for Workgroups'' et les versions suivantes de Windows.
Il est plus rapide et plus sur. Utilisez plutôt samba.</p>
</body>
</html>
|