NFS : 'rcpidmapd' is not a valid service name

[PengouinPdt]

Bonjour,

j'essaye de me connecter à SME par le biais du protocole NFS.
Le lancement du service NFS retourne ces informations :

Code: Tout sélectionner

D�marrage des services NFS :                               [  OK  ]
D�but du quota NFS :                                       [  OK  ]
D�marrage du d�mon NFS :                                   [  OK  ]
D�marrage de NFS mountd :                                  [  OK  ]
'rpcidmapd' is not a valid service name


J'ai modifié le fichier /etc/exports ainsi :

Code: Tout sélectionner

/home/e-smith/files/ibays/informatique/files 10.133.173.200(rw,all_squash,sync)


De fait, depuis ma station lorsque j'essaye d'atteindre en terminal pour le monter, j'ai cette réponse :

mount.nfs 10.133.173.4:/home/e-smith/files/ibays/informatique/files /home/zou/Bureau/srvrs/SME-Informatique/
mount.nfs: mount system call failed

j'avoue que je suis un peu perdu.
Que puis-je faire, (sachant que c'est ma première expérience avec NFS), quoi vérifier ?

[PengouinPdt]

C'est quoi qui ne vas pas ou qui manque dans mon post ci-dessus, pour ne pas avoir de réponse ?

Je suis le seul à vouloir nfs sur sme ?!

[jdh]

Beh euh, il faut en effet connaitre SME et avoir envie d'utiliser nfs.

Par exemple, dans un réseau autour d'un domaine Windows, il parait plus simple d'utiliser smb et non nfs, parce que le client nfs n'est pas naturel sous Windows.

Même pour un serveur Unix/Linux, il suffit d'un smbfs pour accéder à un partage smb (Windows).

Et ceci bien que smb soit un protocole très verbeux et moins performant que nfs. Avec un même hardware, il est plus que probable qu'un partage ibay (c'est à dire smb) sera bien plus performant qu'un serveur Windows : en effet ext3 est plus efficace que ntfs.

[JeB]

Beh euh, il faut en effet connaitre SME et avoir envie d'utiliser nfs.

Par exemple, dans un réseau autour d'un domaine Windows, il parait plus simple d'utiliser smb et non nfs, parce que le client nfs n'est pas naturel sous Windows.

Même pour un serveur Unix/Linux, il suffit d'un smbfs pour accéder à un partage smb (Windows).

Et ceci bien que smb soit un protocole très verbeux et moins performant que nfs. Avec un même hardware, il est plus que probable qu'un partage ibay (c'est à dire smb) sera bien plus performant qu'un serveur Windows : en effet ext3 est plus efficace que ntfs.

NFS + NIS permet une gestion des droits beaucoup plus puissante que samba.

J'utilise ce couple sur une sme 6.01. J'ai dût installé une crontrib spécifique pour cela.

PengouinPdt, il faut en dire plus sur ta configuration - quelle contrib as tu installé ?

JeB.

[jdh]

Je ne dis pas le contraire sur NFS+NIS.

Mais il n'est pas interdit d'utiliser acl sur le file system (avec les traditionnels setfacl/getfacl). De plus, le client nfs n'est pas standard sous Windows (enfin je peux me tromper sauf "NFS services for Windows" alias SFU totalement lourdingue !).

[jibe]

Salut,

C'est vrai que mettre en place NFS sur SME est une idée assez saugrenue. Mais peut-être cela répond-il à un besoin ?

Je l'ai fait sur la mienne perso, à un moment où c'était plus simple pour faire mes sauvegardes avec Affa. Depuis, cette contrib a évolué, et je n'utilise chez mes clients plus que Samba.

Je n'ai plus du tout en tête comment j'avais fait pour installer NFS. Il me semble que ce n'était pas si simple que ça en a l'air (ne pas oublier que SME n'est pas un linux vraiment ordinaire, entre autres à cause des templates qui génèrent les fichiers de config).

Vérifie déjà l'installation, la version. Sur ma SME 7.4 :
nfs-utils-1.0.6-93.EL4
nfs-utils-lib-1.0.6-10.el4

Si ce n'est pas déjà fait, lance une recherche sur ce forum et sur Google : je ne crois pas que je m'étais contenté de trouver les bons rpm : il me semble bien que j'avais trouvé un tuto, howto ou autre procédure d'installation...

[EDIT] Ooops ! lu un peu vite, et pas vu qu'il s'agit de te connecter par le protocole NFS, pas seulement de monter un partage NFS...

Du coup, je rejoins jdh : c'est vraiment une drôle d'idée, et sauf réelle, sérieuse et bonne raison, il vaut beaucoup mieux utiliser samba ! Tu as ici un excellent tuto - que je viens tout juste d'expérimenter avec bonheur - pour connecter des postes linux à un domaine samba/sme...

Crois pas que quelqu'un ait déjà tenté ce que tu cherches à faire... Si NFS t'est indispensable, pose-toi la question de savoir si SME est le serveur adapté à ton cas : AMHA, non...

[PengouinPdt]

En effet, j'ai certainement tort de vouloir le faire.
En effet, la connexion fonctionne très bien, par le biais du protocole SaMBa. Y'a rien à redire là-dessus ...
À moins que je ne veuille synchroniser mes données, et ne pas faire qu'un simple copier-coller.

Comme la synchronisation avec rsync sur nfs, en direction de l'autre serveur NAS (freenas 0.7) fonctionne très bien ... je me suis dit que je pourrais faire la même chose avec SME.

La synchronisation des données avec Affa, de SME vers FreeNAS fonctionne tout aussi bien
(mais ce n'est pas le propos).

Parce que malheureusement, j'essaye de synchroniser mes données par SaMBa grâce à rsync, et ça plantouille !

---

Pour le propos ...

J'ai un server SME 7.4 sur lequel se connecte mes utilisateurs dont moi - je suis le seul à le faire, à partir de mon laptop, sous Ubuntu - les autres le font partir de Windows XP SP3 (deux autres le font en plus, aussi, partir de MacOS X (10.5 et 10.6).
Le FreeNAS assure la sauvegarde des données du SME par le biais d'Affa.
Je sauvegarde des données - qui me sont importantes - directement sur le NAS par création du point de montage dans mon fichier fstab, et rsync. - accès que je suis le seul à avoir.
(mes utilisateurs savent qu'il existe un serveur de sauvegarde, mais qu'ils n'y ont pas accès)
Pour des raisons 'xyz', il faut absolument que mes données soient aussi dans un répertoire partagée de SME, une ibay en particulier, au cas où pour des raisons 'abc', je ne serais plus en poste. (préparer toute relève ...)
Bref, j'ai donc besoin de synchroniser aussi vers cette ibay. Avec Rsync, ça part en vrille ... d'où l'idée d'utiliser nfs pour cela :p

voili, voilou

[jdh]

J'évoque un cas perso qui peut peut-être t'inspirer ...


J'ai 2 serveurs Windows 2003 (de domaines différents) qui doivent synchroniser l'un et l'autre un "Réception" et un "Emission" ("Réception" de l'un doit correspondre à "Emission" de l'autre et lycée de versailles).

(Précédemment était en place BackupExec Replication : efficace mais très couteux !)

Après quelques essais (xcopy, robocopy, cwrsync), je suis arrivé à DeltaCopy.

DeltaCopy est un service (qui tourne sous l'identité System) + un pgm de configuration permettant de créer les partages et les "batchs" de synchro (en fait c'est une "ligne rsync configurée").

Moyennant 2 batchs (de chaque côté) positionnant des droits fixes (via icacls) et tournant avant et après le "pgm" DeltaCopy, cela a fini par fonctionner de façon très correcte.

Bilan : les droits sont fixes et en dur, mais rsync est très efficace pour ne transférer que le delta.

[JeB]

Je ne dis pas le contraire sur NFS+NIS.

Mais il n'est pas interdit d'utiliser acl sur le file system (avec les traditionnels setfacl/getfacl). De plus, le client nfs n'est pas standard sous Windows (enfin je peux me tromper sauf "NFS services for Windows" alias SFU totalement lourdingue !).

J'utilise SFU sous windows. Cela reste assez simple à mettre en place.
Ce qui est effectivement lourdingue, c'est le temps que met un explorer windows à afficher les connexions réseaux lors de sa première ouverture.

En faites pour répondre au reste de la discussion, je suis venu naturellement à NFS+NIS parce que j'ai besoin d'un système d'authentification simple & bien documenté (NIS) pouvant être mis en place sur Mac os / Linux et windows. Donc pour la partage réseau, NFS c'est imposé.
Une autre contrainte, c'est que l'authentification doit fonctionner pour un portable hors réseau (NIS le permet si on a un miroir local de la conf NIS sur le portable)
Tout ca, c'était il y a 4-5 ans.

Je ne connaissais pas alors les acl.
Mais il y a peut être des solutions simple (et gratuite) pour s'authentifier avec Mac os ou linux sur un domaine windows ?

JeB.

[jdh]

SFU s'installe sur un serveur et permet de "redistribuer" le partage NFS d'un serveur Unix (avec l'identifiant indiqué à la création de l'accès). Bref c'est tout sauf sûr.

Il existe des clients non gratuits de NFS chez Tun (Esker) et d'autres (hummingbird ?).


Les Mac sont depuis OS X clients naturels Windows car ils embarquent Samba.
Les machine Linux utilisent Samba et peuvent aussi monter un partage windows (smbfs). (C'est même hyper-simple avec des distributions desktop comme Ubuntu.)
Certains Unix récents supportent aussi Samba.

Le point clé, c'est que sous Windows, on créé un partage windows avec des droits Lecture/Modif/Contrôle total avec bien souvent "Toute le monde", et que ce partage s'appuie sur un répertoire sur un disque NTFS avec lui-même des droits encore plus fin.
Or le droit réel est l'intersection du "droit de partage" et du "droit fichier".
En pratique, il est conseillé de prendre un droit "Contrôle total" en "droit de partage" puis d'ajuster les autorisations avec les droits NTFS.

De plus, sous Windows, les sous répertoires peuvent ou non hériter des droits du répertoire supérieur.

Sous Samba, il ne me semble actif que les "droits de partage" (je ne sais pas si on peut affiner avec les acl au niveau sous-répertoires ...)

Tout cela créé une différence subtile mais nette.


NIS quand à lui offre la possibilité de "centraliser" l'identification utilisateur, à la manière d'ActiveDir. Donc 2 serveurs pourront gérer le même utilisateur alors qu'il serait bien difficile de s'assurer qu'il porte le même n° d'utilisateur et de groupe s'il fallait faire des "adduser" (ou équivalents).

C'est une façon de procéder mais NIS ou pas, les droits Unix reste élémentaire : user/groupe/other=rest of the world ...