In article <1iuavnr.1x31solc0f3zlN%, (Laurent Pertois) wrote:
J.P. Poindessault wrote:
> Si vous me dites comment faire pour que le document arrivé sur le poste > client > devienne RW pour lui, je suis preneur.
Il a quoi à la base côté serveur ?
le dossier où se trouve les documents est readonly pour staff. Pas d'ACL
Jean-Pierre
laurent.pertois
J.P. Poindessault wrote:
> Il a quoi à la base côté serveur ?
le dossier où se trouve les documents est readonly pour staff. Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce que les bases utilisateurs ne sont pas identiques. Ton serveur a une base d'utilisateurs qui lui est propre et tes machines ont la leur. Quand le client se connecte il doit faire un mappage et donc fait croire (si on regarde en terminal c'est encore plus flagrant) qu'il est propriétaire de tous les éléments du partage et il applique à ce faux propriétaire le droits qui sont envoyés par le serveur au niveau de l'utilisateur selon les réglages serveurs. Dans ton cas, quand un utilisateur se connecte il est membre de staff sur le serveur, ce sont les autorisations du niveau groupe qui lui sont appliquées, si on regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il est propriétaire (pour de faux, je répète) avec les droits équivalents au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont équivalents à ceux des Autres du serveur et pour les autres, côté Mac toujours, ils sont soit néants soit équivalents à ceux des Autres du serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté client on décale tous les droits vers la gauche d'autant de crans que nécessaires pour mettre le compte utilisateur propriétaire avec les droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur, après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP) et n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui définit un droit d'écriture sur les fichiers créés pour le propriétaire et voir si ça fonctionne...
On en reparle la semaine prochaine ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
le dossier où se trouve les documents est readonly pour staff.
Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce
que les bases utilisateurs ne sont pas identiques. Ton serveur a une
base d'utilisateurs qui lui est propre et tes machines ont la leur.
Quand le client se connecte il doit faire un mappage et donc fait croire
(si on regarde en terminal c'est encore plus flagrant) qu'il est
propriétaire de tous les éléments du partage et il applique à ce faux
propriétaire le droits qui sont envoyés par le serveur au niveau de
l'utilisateur selon les réglages serveurs. Dans ton cas, quand un
utilisateur se connecte il est membre de staff sur le serveur, ce sont
les autorisations du niveau groupe qui lui sont appliquées, si on
regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il
est propriétaire (pour de faux, je répète) avec les droits équivalents
au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont
équivalents à ceux des Autres du serveur et pour les autres, côté Mac
toujours, ils sont soit néants soit équivalents à ceux des Autres du
serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté
client on décale tous les droits vers la gauche d'autant de crans que
nécessaires pour mettre le compte utilisateur propriétaire avec les
droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu
naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je
réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec
leur login/mdp du serveur, après avoir relié leur Mac au domaine Open
Directory, ce serait différent car alors le Mac partagerait la même base
de comptes que le serveur (que celui-ci rend disponible via LDAP) et
n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui
définit un droit d'écriture sur les fichiers créés pour le propriétaire
et voir si ça fonctionne...
On en reparle la semaine prochaine ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
le dossier où se trouve les documents est readonly pour staff. Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce que les bases utilisateurs ne sont pas identiques. Ton serveur a une base d'utilisateurs qui lui est propre et tes machines ont la leur. Quand le client se connecte il doit faire un mappage et donc fait croire (si on regarde en terminal c'est encore plus flagrant) qu'il est propriétaire de tous les éléments du partage et il applique à ce faux propriétaire le droits qui sont envoyés par le serveur au niveau de l'utilisateur selon les réglages serveurs. Dans ton cas, quand un utilisateur se connecte il est membre de staff sur le serveur, ce sont les autorisations du niveau groupe qui lui sont appliquées, si on regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il est propriétaire (pour de faux, je répète) avec les droits équivalents au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont équivalents à ceux des Autres du serveur et pour les autres, côté Mac toujours, ils sont soit néants soit équivalents à ceux des Autres du serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté client on décale tous les droits vers la gauche d'autant de crans que nécessaires pour mettre le compte utilisateur propriétaire avec les droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur, après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP) et n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui définit un droit d'écriture sur les fichiers créés pour le propriétaire et voir si ça fonctionne...
On en reparle la semaine prochaine ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
J.P. Poindessault
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
J.P. Poindessault wrote:
> > Il a quoi à la base côté serveur ? > > le dossier où se trouve les documents est readonly pour staff. > Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce que les bases utilisateurs ne sont pas identiques. Ton serveur a une base d'utilisateurs qui lui est propre et tes machines ont la leur. Quand le client se connecte il doit faire un mappage et donc fait croire (si on regarde en terminal c'est encore plus flagrant) qu'il est propriétaire de tous les éléments du partage et il applique à ce faux propriétaire le droits qui sont envoyés par le serveur au niveau de l'utilisateur selon les réglages serveurs. Dans ton cas, quand un utilisateur se connecte il est membre de staff sur le serveur, ce sont les autorisations du niveau groupe qui lui sont appliquées, si on regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il est propriétaire (pour de faux, je répète) avec les droits équivalents au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont équivalents à ceux des Autres du serveur et pour les autres, côté Mac toujours, ils sont soit néants soit équivalents à ceux des Autres du serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté client on décale tous les droits vers la gauche d'autant de crans que nécessaires pour mettre le compte utilisateur propriétaire avec les droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur, après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP) et n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui définit un droit d'écriture sur les fichiers créés pour le propriétaire et voir si ça fonctionne...
On en reparle la semaine prochaine ?
OK, merci.
JP
In article <1iublbg.1q6ljse1keefrlN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
> > Il a quoi à la base côté serveur ?
>
> le dossier où se trouve les documents est readonly pour staff.
> Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce
que les bases utilisateurs ne sont pas identiques. Ton serveur a une
base d'utilisateurs qui lui est propre et tes machines ont la leur.
Quand le client se connecte il doit faire un mappage et donc fait croire
(si on regarde en terminal c'est encore plus flagrant) qu'il est
propriétaire de tous les éléments du partage et il applique à ce faux
propriétaire le droits qui sont envoyés par le serveur au niveau de
l'utilisateur selon les réglages serveurs. Dans ton cas, quand un
utilisateur se connecte il est membre de staff sur le serveur, ce sont
les autorisations du niveau groupe qui lui sont appliquées, si on
regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il
est propriétaire (pour de faux, je répète) avec les droits équivalents
au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont
équivalents à ceux des Autres du serveur et pour les autres, côté Mac
toujours, ils sont soit néants soit équivalents à ceux des Autres du
serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté
client on décale tous les droits vers la gauche d'autant de crans que
nécessaires pour mettre le compte utilisateur propriétaire avec les
droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu
naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je
réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec
leur login/mdp du serveur, après avoir relié leur Mac au domaine Open
Directory, ce serait différent car alors le Mac partagerait la même base
de comptes que le serveur (que celui-ci rend disponible via LDAP) et
n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui
définit un droit d'écriture sur les fichiers créés pour le propriétaire
et voir si ça fonctionne...
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
J.P. Poindessault wrote:
> > Il a quoi à la base côté serveur ? > > le dossier où se trouve les documents est readonly pour staff. > Pas d'ACL
En fait, le soucis vient du mappage utilisateur fait par le client parce que les bases utilisateurs ne sont pas identiques. Ton serveur a une base d'utilisateurs qui lui est propre et tes machines ont la leur. Quand le client se connecte il doit faire un mappage et donc fait croire (si on regarde en terminal c'est encore plus flagrant) qu'il est propriétaire de tous les éléments du partage et il applique à ce faux propriétaire le droits qui sont envoyés par le serveur au niveau de l'utilisateur selon les réglages serveurs. Dans ton cas, quand un utilisateur se connecte il est membre de staff sur le serveur, ce sont les autorisations du niveau groupe qui lui sont appliquées, si on regarde sur le Mac de cet utilisateur on verra, sur le partage, qu'il est propriétaire (pour de faux, je répète) avec les droits équivalents au groupe. Les droits du groupe, côté Mac (toujours pour de faux) sont équivalents à ceux des Autres du serveur et pour les autres, côté Mac toujours, ils sont soit néants soit équivalents à ceux des Autres du serveur encore (j'ai un doute sur le coup, j'avoue). En fait, côté client on décale tous les droits vers la gauche d'autant de crans que nécessaires pour mettre le compte utilisateur propriétaire avec les droits afférents au compte de connexion serveur.
Je ne sais pas si je suis clair, pour le coup mais j'avoue être un peu naze après 3 semaines intensives à Abu Dhabi. Il faudrait que je réfléchisse à un schéma de ce principe un jour.
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur, après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP) et n'aurait pas à faire ce mappage un peu tordu.
Dernière solution, il faudrait tenter d'appliquer sur le Mac une ACL qui définit un droit d'écriture sur les fichiers créés pour le propriétaire et voir si ça fonctionne...
On en reparle la semaine prochaine ?
OK, merci.
JP
Jacques Perrocheau
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la main".
et n'aurait pas à faire ce mappage un peu tordu.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1iublbg.1q6ljse1keefrlN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec
leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
après avoir relié leur Mac au domaine Open Directory, ce serait
différent car alors le Mac partagerait la même base de comptes que le
serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la
main".
et n'aurait pas à faire ce mappage un peu tordu.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
Par contre si tes utilisateurs ouvraient une session sur leur Mac avec leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
après avoir relié leur Mac au domaine Open Directory, ce serait différent car alors le Mac partagerait la même base de comptes que le serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la main".
et n'aurait pas à faire ce mappage un peu tordu.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
J.P. Poindessault
In article <4981eeb6$0$21839$, Jacques Perrocheau wrote:
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
> Par contre si tes utilisateurs ouvraient une session sur leur Mac avec > leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
> après avoir relié leur Mac au domaine Open Directory, ce serait > différent car alors le Mac partagerait la même base de comptes que le > serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la main".
> et n'aurait pas à faire ce mappage un peu tordu.
Les utilisateurs se connectent sur leur poste avec le même login/pwd que sur le serveur.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Jean-Pierre
In article <4981eeb6$0$21839$426a74cc@news.free.fr>,
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
In article <1iublbg.1q6ljse1keefrlN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
> Par contre si tes utilisateurs ouvraient une session sur leur Mac avec
> leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
> après avoir relié leur Mac au domaine Open Directory, ce serait
> différent car alors le Mac partagerait la même base de comptes que le
> serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la
main".
> et n'aurait pas à faire ce mappage un peu tordu.
Les utilisateurs se connectent sur leur poste avec le même login/pwd que sur le
serveur.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
In article <4981eeb6$0$21839$, Jacques Perrocheau wrote:
In article <1iublbg.1q6ljse1keefrlN%, (Laurent Pertois) wrote:
> Par contre si tes utilisateurs ouvraient une session sur leur Mac avec > leur login/mdp du serveur,
Oui, cela me semblerait plus "sain".
> après avoir relié leur Mac au domaine Open Directory, ce serait > différent car alors le Mac partagerait la même base de comptes que le > serveur (que celui-ci rend disponible via LDAP)
Ouep, sûrement dès que le nombre de comptes n'est plus gérable "à la main".
> et n'aurait pas à faire ce mappage un peu tordu.
Les utilisateurs se connectent sur leur poste avec le même login/pwd que sur le serveur.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Jean-Pierre
laurent.pertois
J.P. Poindessault wrote:
Les utilisateurs se connectent sur leur poste avec le même login/pwd que sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la base locale de leur machine (ex base NetInfo, maintenant DSLocal). De plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils existent donc à deux endroits, certes avec les mêmes noms et mot de passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne seraient pas créés sur leur ordinateur, ils utiliseraient le compte déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur serait relié. Du coup, quand un utilisateur ouvre une session avec un tel système, la base utilisateur du serveur est commune avec l'une de celles utilisées par le client et tout le monde a les mêmes UID (et UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes de mappages.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où c'est le pire, ou disons moins pratique, effectivement.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Les utilisateurs se connectent sur leur poste avec le même login/pwd que
sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la
base locale de leur machine (ex base NetInfo, maintenant DSLocal). De
plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils
existent donc à deux endroits, certes avec les mêmes noms et mot de
passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne
seraient pas créés sur leur ordinateur, ils utiliseraient le compte
déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur
serait relié. Du coup, quand un utilisateur ouvre une session avec un
tel système, la base utilisateur du serveur est commune avec l'une de
celles utilisées par le client et tout le monde a les mêmes UID (et
UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes
de mappages.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où
c'est le pire, ou disons moins pratique, effectivement.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Les utilisateurs se connectent sur leur poste avec le même login/pwd que sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la base locale de leur machine (ex base NetInfo, maintenant DSLocal). De plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils existent donc à deux endroits, certes avec les mêmes noms et mot de passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne seraient pas créés sur leur ordinateur, ils utiliseraient le compte déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur serait relié. Du coup, quand un utilisateur ouvre une session avec un tel système, la base utilisateur du serveur est commune avec l'une de celles utilisées par le client et tout le monde a les mêmes UID (et UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes de mappages.
Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où c'est le pire, ou disons moins pratique, effectivement.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
J.P. Poindessault
In article <1iuekyl.10qsbnn18k2mgmN%, (Laurent Pertois) wrote:
J.P. Poindessault wrote:
> Les utilisateurs se connectent sur leur poste avec le même login/pwd que > sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la base locale de leur machine (ex base NetInfo, maintenant DSLocal). De plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils existent donc à deux endroits, certes avec les mêmes noms et mot de passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne seraient pas créés sur leur ordinateur, ils utiliseraient le compte déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur serait relié. Du coup, quand un utilisateur ouvre une session avec un tel système, la base utilisateur du serveur est commune avec l'une de celles utilisées par le client et tout le monde a les mêmes UID (et UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes de mappages.
> Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où c'est le pire, ou disons moins pratique, effectivement.
OK. Ce n'est pas un peu compliqué pour faire de l'échange de fichiers épisodique ? Si j'ai bien compris, le client a un home complet sur le serveur et son poste devient en gros un terminal, le périphérique n'est plus le serveur mais le poste local. Pas zen ça pour ce que j'avais monté sous 10.3.
Jean-Pierre
In article <1iuekyl.10qsbnn18k2mgmN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
> Les utilisateurs se connectent sur leur poste avec le même login/pwd que
> sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la
base locale de leur machine (ex base NetInfo, maintenant DSLocal). De
plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils
existent donc à deux endroits, certes avec les mêmes noms et mot de
passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne
seraient pas créés sur leur ordinateur, ils utiliseraient le compte
déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur
serait relié. Du coup, quand un utilisateur ouvre une session avec un
tel système, la base utilisateur du serveur est commune avec l'une de
celles utilisées par le client et tout le monde a les mêmes UID (et
UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes
de mappages.
> Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où
c'est le pire, ou disons moins pratique, effectivement.
OK.
Ce n'est pas un peu compliqué pour faire de l'échange de fichiers épisodique ?
Si j'ai bien compris, le client a un home complet sur le serveur et son poste
devient en gros un terminal, le périphérique n'est plus le serveur mais le poste
local.
Pas zen ça pour ce que j'avais monté sous 10.3.
In article <1iuekyl.10qsbnn18k2mgmN%, (Laurent Pertois) wrote:
J.P. Poindessault wrote:
> Les utilisateurs se connectent sur leur poste avec le même login/pwd que > sur le serveur.
Là n'est pas la question en fait. Tes utilisateurs sont déclarés dans la base locale de leur machine (ex base NetInfo, maintenant DSLocal). De plus, tu as recréé ces utilisateurs dans la base de ton serveur. Ils existent donc à deux endroits, certes avec les mêmes noms et mot de passe mais ce ne sont pas les mêmes comptes.
Avec une structure partagée, type Open Directory, tes utilisateurs ne seraient pas créés sur leur ordinateur, ils utiliseraient le compte déclaré sur le serveur dans la base LDAP à laquelle leur ordinateur serait relié. Du coup, quand un utilisateur ouvre une session avec un tel système, la base utilisateur du serveur est commune avec l'une de celles utilisées par le client et tout le monde a les mêmes UID (et UUID) et les reconnait, il n'est pas nécessaire de faire des pirouettes de mappages.
> Ce problème existe depuis 10.5 et n'existait pas sous 10.3.9
Il y a eu de gros changements, souvent en mieux, tu es dans le cas où c'est le pire, ou disons moins pratique, effectivement.
OK. Ce n'est pas un peu compliqué pour faire de l'échange de fichiers épisodique ? Si j'ai bien compris, le client a un home complet sur le serveur et son poste devient en gros un terminal, le périphérique n'est plus le serveur mais le poste local. Pas zen ça pour ce que j'avais monté sous 10.3.
