soit un GNU/Linux Debian (petisuix 192.168.0.20) PPC avec l'utilisateur
seki uid(1000):gid(1000),
sur le même sous-réseau j'ai une PWS 500a (lucie 192.168.0.140) tournant
sous Tru64 / Digital Unix / OSF1 (je ne sais pas exactement comment je
dois l'appeler[1]) sur lequel j'ai ajouté l'utilisateur
seki uid(204):gid(15)
Sur lucie je souhaite pour l'utilisateur seki accéder au répertoire
~/.gnus.d de l'utilisateur seki de petisuix.
J'ai donc ajouté cette ligne dans mon /etc/exports de petisuix :
,----[ exports ]
| /home/seki 192.168.0.0/24(rw,sync)
|
`----
Sur lucie, seki a créé le point de montage /usr/users/seki/.gnus.d (oui,
bizarrement le home est dans /usr/users) puis en root j'effectue le
montage par un
/sbin/mount petisuix:/home/seki/.gnus.d /usr/users/seki/.gnus.d
Je vois ceci dans les montages sur lucie :
petisuix:/home/seki/.gnus.d on /usr/users/seki/.gnus.d type nfs (v3, rw,
udp, hard, intr)
Mon problème c'est qu'alors que le point de montage sur lucie appartient
à seki:users, une fois le montage effectué il appartient à 1000:1000 ce
qui ressemble à mon couple uid:gid de l'utilisateur sur petisuix. L'utilisateur
de lucie n'a plus alors le droit d'écrire dans le répertoire et je suis
coincé.
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur
du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté
d'ajouter dans exports les options anonuid et anongid avec des valeurs
1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se
modifier lors d'un remontage.
Un peu d'aide serait grandement appréciée.
[1] en fait au login je vois : Compaq Tru64 UNIX V5.1B (Rev. 2650); Mon
Sep 8 13:13:13 CEST 2003
et un uname -a retourne : OSF1 lucie V5.1 2650 alpha
--
Sébastien Kirche
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30, Sébastien Kirche disait:
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté d'ajouter dans exports les options anonuid et anongid avec des valeurs 1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste. -- panic("huh?n"); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30,
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> disait:
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur
du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté
d'ajouter dans exports les options anonuid et anongid avec des valeurs
1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se
modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen
de changer le mapping des UID. C'est cependant quelque chose de
faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est
plus maintenu, cela ne semble pas être une bonne solution.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle
"ugidd" et qui semble servir à faire du mapping. C'est en paquet
Debian, tu peux p'tet explorer cette piste.
--
panic("huh?n");
2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30, Sébastien Kirche disait:
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté d'ajouter dans exports les options anonuid et anongid avec des valeurs 1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste. -- panic("huh?n"); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
Sébastien Kirche
Le 11 July 2006 à 11:13, Vincent Bernat s'est exprimé ainsi :
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30, Sébastien Kirche disait:
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté d'ajouter dans exports les options anonuid et anongid avec des valeurs 1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon point de montage lorsque j'effectue le montage nfs ? Je ne vois pas d'uid 1000 dans le /etc/passwd de Tru64.
Éventuellement je pourrais faire un essai avec le serveur en userland, c'est pour une utilisation sur mon réseau perso.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un réglage qu'on peut appliquer localement sur le serveur alors que les machines causent en v3 ?
Merci pour ta réponse.
-- Sébastien Kirche
Le 11 July 2006 à 11:13, Vincent Bernat s'est exprimé ainsi :
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30,
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> disait:
Est-ce que cette appartenance 1000:1000 représente bien mon
utilisateur du côté du serveur nfs ? ET comment je peux corriger ça
? J'ai tenté d'ajouter dans exports les options anonuid et anongid
avec des valeurs 1000:1000 puis 204:15 mais je n'ai pas vu les
droits du répertoire se modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen
de changer le mapping des UID. C'est cependant quelque chose de
faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est
plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon
point de montage lorsque j'effectue le montage nfs ? Je ne vois pas
d'uid 1000 dans le /etc/passwd de Tru64.
Éventuellement je pourrais faire un essai avec le serveur en userland,
c'est pour une utilisation sur mon réseau perso.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle
"ugidd" et qui semble servir à faire du mapping. C'est en paquet
Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un
réglage qu'on peut appliquer localement sur le serveur alors que les
machines causent en v3 ?
Le 11 July 2006 à 11:13, Vincent Bernat s'est exprimé ainsi :
OoO En cette matinée pluvieuse du mardi 11 juillet 2006, vers 10:30, Sébastien Kirche disait:
Est-ce que cette appartenance 1000:1000 représente bien mon utilisateur du côté du serveur nfs ? ET comment je peux corriger ça ? J'ai tenté d'ajouter dans exports les options anonuid et anongid avec des valeurs 1000:1000 puis 204:15 mais je n'ai pas vu les droits du répertoire se modifier lors d'un remontage.
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon point de montage lorsque j'effectue le montage nfs ? Je ne vois pas d'uid 1000 dans le /etc/passwd de Tru64.
Éventuellement je pourrais faire un essai avec le serveur en userland, c'est pour une utilisation sur mon réseau perso.
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un réglage qu'on peut appliquer localement sur le serveur alors que les machines causent en v3 ?
Merci pour ta réponse.
-- Sébastien Kirche
Vincent Bernat
OoO En cette fin de matinée radieuse du mardi 11 juillet 2006, vers 11:25, Sébastien Kirche disait:
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon point de montage lorsque j'effectue le montage nfs ? Je ne vois pas d'uid 1000 dans le /etc/passwd de Tru64.
Les droits du serveur sont exportés sur le client. C'est pour ça qu'il est plus pratique d'avoir les uid synchros entre les deux machines. Si tu n'exportes que ton home à toi, tu peux utiliser des options pour donner tous les fichiers à tel uid (celui de ton utilisateur sur Tru64). Regarde exports(5). Tu dois sans doute utiliser all_squash et anonuid. Ou squash_uid et anonuid. Ah, tiens, y'a mieux...
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un réglage qu'on peut appliquer localement sur le serveur alors que les machines causent en v3 ?
D'après le exports(5), l'option map_daemon semble indépendante de la version de NFS. Par contre, il te faudra compiler rpc.ugidd sur Tru64. Cela dit, je peux pas t'en dire plus, j'ai jamais essayé. -- panic("Lucy in the sky...."); 2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
OoO En cette fin de matinée radieuse du mardi 11 juillet 2006, vers
11:25, Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid>
disait:
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen
de changer le mapping des UID. C'est cependant quelque chose de
faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est
plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon
point de montage lorsque j'effectue le montage nfs ? Je ne vois pas
d'uid 1000 dans le /etc/passwd de Tru64.
Les droits du serveur sont exportés sur le client. C'est pour ça qu'il
est plus pratique d'avoir les uid synchros entre les deux machines. Si
tu n'exportes que ton home à toi, tu peux utiliser des options pour
donner tous les fichiers à tel uid (celui de ton utilisateur sur
Tru64). Regarde exports(5). Tu dois sans doute utiliser all_squash et
anonuid. Ou squash_uid et anonuid. Ah, tiens, y'a mieux...
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle
"ugidd" et qui semble servir à faire du mapping. C'est en paquet
Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un
réglage qu'on peut appliquer localement sur le serveur alors que les
machines causent en v3 ?
D'après le exports(5), l'option map_daemon semble indépendante de la
version de NFS. Par contre, il te faudra compiler rpc.ugidd sur
Tru64. Cela dit, je peux pas t'en dire plus, j'ai jamais essayé.
--
panic("Lucy in the sky....");
2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
OoO En cette fin de matinée radieuse du mardi 11 juillet 2006, vers 11:25, Sébastien Kirche disait:
En NFSv3, avec le serveur NFS dans le noyau Linux, il n'y a pas moyen de changer le mapping des UID. C'est cependant quelque chose de faisable avec le serveur NFS en userland. Toutefois, celui-ci n'est plus maintenu, cela ne semble pas être une bonne solution.
Ah. Mais d'où vient ce changement de seki:users -> 1000:1000 de mon point de montage lorsque j'effectue le montage nfs ? Je ne vois pas d'uid 1000 dans le /etc/passwd de Tru64.
Les droits du serveur sont exportés sur le client. C'est pour ça qu'il est plus pratique d'avoir les uid synchros entre les deux machines. Si tu n'exportes que ton home à toi, tu peux utiliser des options pour donner tous les fichiers à tel uid (celui de ton utilisateur sur Tru64). Regarde exports(5). Tu dois sans doute utiliser all_squash et anonuid. Ou squash_uid et anonuid. Ah, tiens, y'a mieux...
Dans NFSv4, il y a désormais utilisation d'un démon qui s'appelle "ugidd" et qui semble servir à faire du mapping. C'est en paquet Debian, tu peux p'tet explorer cette piste.
Cependant le client de Tru64 ne connaît pas nfsv4. Est-ce que c'est un réglage qu'on peut appliquer localement sur le serveur alors que les machines causent en v3 ?
D'après le exports(5), l'option map_daemon semble indépendante de la version de NFS. Par contre, il te faudra compiler rpc.ugidd sur Tru64. Cela dit, je peux pas t'en dire plus, j'ai jamais essayé. -- panic("Lucy in the sky...."); 2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
