#exportfs

on the NFS server, create or edit exisiting /etc/exports file and add entries based on following format:

[directory_to_be_shared] [-rw | -ro],access=[nfs_client_fqdn],root=[nfs_client_fqdn]

save the file and then made sure rpc.mountd, portmap and nfsd are all running.  if not, start them (and also, don't forget to export the fs):

# startsrc -s rpc.mountd # startsrc -s portmap # startsrc -g nfs # exportfs -a

on the client, mount the filesystem with:

Bonjour à tous!

Aaaahh, enfin un petit billet, ça faisait longtemps. En fait j'avais pas mal de boulot assez répétitif, et surtout pas intéressant en ce qui concerne le blog. Mais là, tout se clos petit à petit, donc du coups, il est temps de faire quelques tutos rapide de solutions simples et efficaces pour les problèmes que j'ai rencontré, car oui, la plupart du temps, les solutions qu'on met plusieurs semaines à trouver sont toutes connes, mais fallait trouver la bonne façon de les aborder.

Aujourd'hui on va donc parler d'un souci qui peut vous avoir été soumis, surtout si vous avez déjà suivit mes tutos sur le NFSRoot.

Voila, imaginez une situation lambda, vous avez un système bombardé en nfsroot, et vous possédez un autre serveur qui se monte dans ce système linux (en gros une architecture classique de développement avec un système et un serveur de fichier qui lui est raccordé.

Vous vous retrouvez donc avec, dans le système linux nfs, un bout de votre fstab qui ressemble plus ou moins à ça : 

nas:/nas /nas nfs4 1 0

C'est une configuration assez intéressante, simple a mettre en place, et loin d'être contestable. Au niveau de la fiabilité, elle est aussi contestable qu'une ou les systèmes serait interne aux machines, dans la mesure ou, en cas de panne du système, le serveur de fichier servirai à rien, et en cas inverse, un système sans serveur de fichier ne permettrait pas de bosser (ou peut être zoner sur Internet, et encore)

Bref, dans une logique de limitation des ressources, et pour en finir avec un serveur de fichier assez vieux et pantouflard, l'idée est venue de tout réunir au sein d'un même serveur. Le système et les données.

  Pour ce faire, et éviter d'exporter depuis ce serveur les fichiers ET le système avec deux lignes dans le fichier d'exportation, on va faire une petite manip pour faire du deux en un. Reprenons notre fichier d'exportation du système Ubuntu en nfsroot (voir tuto : http://dontpanicit.tumblr.com/post/11432209474/installation-dun-systeme-nfsroot-et-le-lancer-via ).

Imaginons qu'en temps normal, notre dossier de serveur de fichier soit à la racine  (monté comme cité plus haut) sous forme de :

/nas

Sa position dans le NFSR(NFSRoot), vue du serveur, serait donc ici :

/srv/ubuntu/nas L'idée c'est donc de monter la partition qui contiens /nas (ou de monter le dossier en bind) directement dans ce dossier, et de lancer notre système, et penser à retirer de notre fstab de notre système ubuntu NFSR la ligne de montage NFS du nas. Donc fstab du serveur : /dev/sda42 /srv/current/nas filesystemtype defaults 1 1 Et plus de trace d'un montage du nas:/dns-nas dans le /srv/current/etc/fstab! Si vous le faites, et que vous lancez votre système, il va démarrer, et un ls -al dans votre dossier /nas va vous montrer que ... ça ne marche pas 8D.

PAS DE PANIQUE!

C'est tout a fait normal. Pour limiter les risques d'intrusion depuis le système jusqu'au serveur, GNU/Linux est justement configuré pour masquer les partitions montées ou disponibles du serveur depuis les clients. C'est une mesure de sécurité tout à fait logique de la part des concepteurs du système d'exports.

Il faut donc trouver les arguments qui vont bien pour justement by-passer cette sécurité en disant à l'exportation de se montrer nu comme un ver lors de son exploitation sur les machines clients.

C'est un lot de 3 options dans le man exportfs de Linux qu'il était important de repérer :

nohide - Première pierre angulaire de notre exportation, elle force les exportations à tout montrer. Nécessaire mais pas suffisante, elle a besoin du complément suivant.

crossmnt - Deuxième pierre, elle sert à montrer précisément les périphériques montés à la source, c'est à dire par le serveur. Et enfin par mesure de précaution pour éviter les conflits de racine, on va poser un petit fsid=0 Qui va quand même garantir la racine du système correctement, et rétablir un semblant de sécurité.

Donc au final notre ligne d'exportation va ressembler à ça :  /srv/current/   192.168.0.0/24(rw,no_root_squash,async,subtree_check,nohide,crossmnt,fsid=0)

NB : Notez la nouvelle façon de noter l'IP, c'est elle la correcte :p. 

C'était vraiment bête comme idée, mais il fallait y penser.

C'est super pratique parce qu'on perd en complexité et on gagne en vitesse de traitement. Maintenant tout est empaqueté à la source, magique!