j'ai 80 utilisateurs macosx, chacun =E0 sa machine avec son
homeDirectory en local.
J'installe au milieu de tout =E7a un osxserver.
Objectif : Avoir un serveur de mot de passe, soit que les clients
s'authentifient sur le serveur avec leur homeDirectory en local.
Question : Est-ce possible ? Si non, pas la peine de lire la suite du
message...
sur le serveur
Je lance la plupart des services dont dhcp et dns bien configur=E9s,
je le d=E9clare ma=EEtre open directory,
authentifi=E9 comme l'admin d'open directory, je cr=E9=E9 un utilisateur
'infonico' sur le serveur ('infonico' c'est moi, utilisateur d=E9j=E0 cr=E9=
=E9
sur ma machine cliente), je ne d=E9clare aucun 'd=E9part' ou homeDirectory
sur le serveur.
sur ma machine
dans l'app format de repertoire, j'active ldapv3, j'ajoute les
serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai
bien mon serveur dans la liste.
Probl=E8me : l'authentification se fait toujours sur ma machine et pas
sur le serveur. Que dois-je faire ?
j'ai 80 utilisateurs macosx, chacun à sa machine avec son homeDirectory en local. J'installe au milieu de tout ça un osxserver.
Objectif : Avoir un serveur de mot de passe, soit que les clients s'authentifient sur le serveur avec leur homeDirectory en local. Question : Est-ce possible ? Si non, pas la peine de lire la suite du message...
sur le serveur Je lance la plupart des services dont dhcp et dns bien configurés, je le déclare maître open directory, authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory sur le serveur.
sur ma machine dans l'app format de repertoire, j'active ldapv3, j'ajoute les serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai bien mon serveur dans la liste.
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Une simple precision tu a bien crée tes users sur le serveur ?
koni a formulé ce mardi :
Bonjour à tous,
j'ai 80 utilisateurs macosx, chacun à sa machine avec son
homeDirectory en local.
J'installe au milieu de tout ça un osxserver.
Objectif : Avoir un serveur de mot de passe, soit que les clients
s'authentifient sur le serveur avec leur homeDirectory en local.
Question : Est-ce possible ? Si non, pas la peine de lire la suite du
message...
sur le serveur
Je lance la plupart des services dont dhcp et dns bien configurés,
je le déclare maître open directory,
authentifié comme l'admin d'open directory, je créé un utilisateur
'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé
sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory
sur le serveur.
sur ma machine
dans l'app format de repertoire, j'active ldapv3, j'ajoute les
serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai
bien mon serveur dans la liste.
Problème : l'authentification se fait toujours sur ma machine et pas
sur le serveur. Que dois-je faire ?
Une simple precision tu a bien crée tes users sur le serveur ?
j'ai 80 utilisateurs macosx, chacun à sa machine avec son homeDirectory en local. J'installe au milieu de tout ça un osxserver.
Objectif : Avoir un serveur de mot de passe, soit que les clients s'authentifient sur le serveur avec leur homeDirectory en local. Question : Est-ce possible ? Si non, pas la peine de lire la suite du message...
sur le serveur Je lance la plupart des services dont dhcp et dns bien configurés, je le déclare maître open directory, authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory sur le serveur.
sur ma machine dans l'app format de repertoire, j'active ldapv3, j'ajoute les serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai bien mon serveur dans la liste.
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Une simple precision tu a bien crée tes users sur le serveur ?
koni
authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà c réé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirect ory sur le serveur.
Une simple precision tu a bien crée tes users sur le serveur ?
oui, c'est ce que j'ai écris dans mon premier message. Bon d'accord, c'était pas très clair...
authentifié comme l'admin d'open directory, je créé un utilisateur
'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà c réé
sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirect ory
sur le serveur.
Une simple precision tu a bien crée tes users sur le serveur ?
oui, c'est ce que j'ai écris dans mon premier message.
Bon d'accord, c'était pas très clair...
authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà c réé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirect ory sur le serveur.
Une simple precision tu a bien crée tes users sur le serveur ?
oui, c'est ce que j'ai écris dans mon premier message. Bon d'accord, c'était pas très clair...
laurent.pertois
koni wrote:
Objectif : Avoir un serveur de mot de passe, soit que les clients s'authentifient sur le serveur avec leur homeDirectory en local. Question : Est-ce possible ? Si non, pas la peine de lire la suite du message...
C'est possible.
sur le serveur Je lance la plupart des services dont dhcp et dns bien configurés, je le déclare maître open directory, authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory sur le serveur.
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire, si tu souhaites vraiment qu'il soit local il faut lui préciser un chemin qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien vérifier que tu es sur la base LDAP et pas la base NetInfo), Home Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
sur ma machine dans l'app format de repertoire, j'active ldapv3, j'ajoute les serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai bien mon serveur dans la liste.
Ok.
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
koni <nicolas.darque@gmail.com> wrote:
Objectif : Avoir un serveur de mot de passe, soit que les clients
s'authentifient sur le serveur avec leur homeDirectory en local.
Question : Est-ce possible ? Si non, pas la peine de lire la suite du
message...
C'est possible.
sur le serveur
Je lance la plupart des services dont dhcp et dns bien configurés,
je le déclare maître open directory,
authentifié comme l'admin d'open directory, je créé un utilisateur
'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé
sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory
sur le serveur.
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire, si
tu souhaites vraiment qu'il soit local il faut lui préciser un chemin
qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien
vérifier que tu es sur la base LDAP et pas la base NetInfo), Home
Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui
s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
sur ma machine
dans l'app format de repertoire, j'active ldapv3, j'ajoute les
serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai
bien mon serveur dans la liste.
Ok.
Problème : l'authentification se fait toujours sur ma machine et pas
sur le serveur. Que dois-je faire ?
Tu as un "infonico" en local sur la machine ? tu es en quelle version de
Mac OS X sur ton poste client ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Objectif : Avoir un serveur de mot de passe, soit que les clients s'authentifient sur le serveur avec leur homeDirectory en local. Question : Est-ce possible ? Si non, pas la peine de lire la suite du message...
C'est possible.
sur le serveur Je lance la plupart des services dont dhcp et dns bien configurés, je le déclare maître open directory, authentifié comme l'admin d'open directory, je créé un utilisateur 'infonico' sur le serveur ('infonico' c'est moi, utilisateur déjà créé sur ma machine cliente), je ne déclare aucun 'départ' ou homeDirectory sur le serveur.
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire, si tu souhaites vraiment qu'il soit local il faut lui préciser un chemin qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien vérifier que tu es sur la base LDAP et pas la base NetInfo), Home Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
sur ma machine dans l'app format de repertoire, j'active ldapv3, j'ajoute les serveurs ldap fournis par dhcp, dans l'onglet "Authentification" j'ai bien mon serveur dans la liste.
Ok.
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
koni
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire , si tu souhaites vraiment qu'il soit local il faut lui préciser un chemin qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien vérifier que tu es sur la base LDAP et pas la base NetInfo), Home Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
Je souhaite qu'il soit local, sur la machine cliente j'entends. Je suis bien sur la base LDAP. J'ai ajouté /Users/infonico dans la dernière case "Départ" de l'utilisateur en question. Si je remplis la case "Chemin", je ne peux pas valider l'enregistrement.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine. Le serveur et le client sont en 10.4.9
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire , si
tu souhaites vraiment qu'il soit local il faut lui préciser un chemin
qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien
vérifier que tu es sur la base LDAP et pas la base NetInfo), Home
Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui
s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
Je souhaite qu'il soit local, sur la machine cliente j'entends.
Je suis bien sur la base LDAP.
J'ai ajouté /Users/infonico dans la dernière case "Départ" de
l'utilisateur en question. Si je remplis la case "Chemin", je ne peux
pas valider l'enregistrement.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de
Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine.
Le serveur et le client sont en 10.4.9
Déjà, pas de Home Directory, ça ne va pas bien fonctionner. Au pire , si tu souhaites vraiment qu'il soit local il faut lui préciser un chemin qui sera lu en local. Dans le Workgroup Manager, utilisateur (bien vérifier que tu es sur la base LDAP et pas la base NetInfo), Home Directory, cliquer sur + en bas, dans la dernière case de la fenêtre qui s'affiche (chemin ou un truc comme ça) taper /Users/nom_abrégé.
Je souhaite qu'il soit local, sur la machine cliente j'entends. Je suis bien sur la base LDAP. J'ai ajouté /Users/infonico dans la dernière case "Départ" de l'utilisateur en question. Si je remplis la case "Chemin", je ne peux pas valider l'enregistrement.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine. Le serveur et le client sont en 10.4.9
laurent.pertois
koni wrote:
Je souhaite qu'il soit local, sur la machine cliente j'entends.
Oui oui, c'est bien ce que je décris.
Je suis bien sur la base LDAP. J'ai ajouté /Users/infonico dans la dernière case "Départ" de l'utilisateur en question. Si je remplis la case "Chemin", je ne peux pas valider l'enregistrement.
Y a un problème, il faut que ce soit dans Chemin et je viens de vérifier, ça valide chez moi.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine.
Ben voilà, quand tu regardes dans Format de Répertoire (Directory Access), Authentification, tu verras que la base locale est au-dessus de ton serveur, donc elle est prioritaire.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
koni <nicolas.darque@gmail.com> wrote:
Je souhaite qu'il soit local, sur la machine cliente j'entends.
Oui oui, c'est bien ce que je décris.
Je suis bien sur la base LDAP.
J'ai ajouté /Users/infonico dans la dernière case "Départ" de
l'utilisateur en question. Si je remplis la case "Chemin", je ne peux
pas valider l'enregistrement.
Y a un problème, il faut que ce soit dans Chemin et je viens de
vérifier, ça valide chez moi.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de
Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine.
Ben voilà, quand tu regardes dans Format de Répertoire (Directory
Access), Authentification, tu verras que la base locale est au-dessus de
ton serveur, donc elle est prioritaire.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Je souhaite qu'il soit local, sur la machine cliente j'entends.
Oui oui, c'est bien ce que je décris.
Je suis bien sur la base LDAP. J'ai ajouté /Users/infonico dans la dernière case "Départ" de l'utilisateur en question. Si je remplis la case "Chemin", je ne peux pas valider l'enregistrement.
Y a un problème, il faut que ce soit dans Chemin et je viens de vérifier, ça valide chez moi.
Tu as un "infonico" en local sur la machine ? tu es en quelle version de Mac OS X sur ton poste client ?
Oui, j'ai un "infonico" en local sur ma machine.
Ben voilà, quand tu regardes dans Format de Répertoire (Directory Access), Authentification, tu verras que la base locale est au-dessus de ton serveur, donc elle est prioritaire.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Laurent Pertois wrote:
Y a un problème, il faut que ce soit dans Chemin et je viens de vérifier, ça valide chez moi.
My mistake, c'est dans Départ et pas dans Chemin, la photo d'écran que tu m'as envoyé m'a permis de corriger.
Bon, je vais aller acheter des lunettes maintenant ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Y a un problème, il faut que ce soit dans Chemin et je viens de
vérifier, ça valide chez moi.
My mistake, c'est dans Départ et pas dans Chemin, la photo d'écran que
tu m'as envoyé m'a permis de corriger.
Bon, je vais aller acheter des lunettes maintenant ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Y a un problème, il faut que ce soit dans Chemin et je viens de vérifier, ça valide chez moi.
My mistake, c'est dans Départ et pas dans Chemin, la photo d'écran que tu m'as envoyé m'a permis de corriger.
Bon, je vais aller acheter des lunettes maintenant ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas.MICHEL
koni wrote:
Question : Est-ce possible ?
oui, bien sûr.
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Te connecter avec un utilisateur du domaine, pas avec un compte local.
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le serveur et un en local, ayant tout deux le même username, alors c'est le compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte local, (faut être logué avec un autre compte) de vérifier que le client est correctement connecté au serveur puis de faire un "chown" du HomeDir. Si le compte est correctement créé sur le serveur, au prochain login tu auras un "network account".
en verbiage technique, ça donne ça : ~> sudo dscl
cd /Netinfo/Users delete toto q ~> id toto
~> sudo chown -R toto /Users/toto
-- Nicolas
koni <nicolas.darque@gmail.com> wrote:
Question : Est-ce possible ?
oui, bien sûr.
Problème : l'authentification se fait toujours sur ma machine et pas
sur le serveur. Que dois-je faire ?
Te connecter avec un utilisateur du domaine, pas avec un compte local.
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le
serveur et un en local, ayant tout deux le même username, alors c'est le
compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils
n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte
local, (faut être logué avec un autre compte) de vérifier que le client
est correctement connecté au serveur puis de faire un "chown" du
HomeDir.
Si le compte est correctement créé sur le serveur, au prochain login tu
auras un "network account".
Problème : l'authentification se fait toujours sur ma machine et pas sur le serveur. Que dois-je faire ?
Te connecter avec un utilisateur du domaine, pas avec un compte local.
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le serveur et un en local, ayant tout deux le même username, alors c'est le compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte local, (faut être logué avec un autre compte) de vérifier que le client est correctement connecté au serveur puis de faire un "chown" du HomeDir. Si le compte est correctement créé sur le serveur, au prochain login tu auras un "network account".
en verbiage technique, ça donne ça : ~> sudo dscl
cd /Netinfo/Users delete toto q ~> id toto
~> sudo chown -R toto /Users/toto
-- Nicolas
mag
Nicolas MICHEL wrote:
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le serveur et un en local, ayant tout deux le même username, alors c'est le compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte local, (faut être logué avec un autre compte) de vérifier que le client est correctement connecté au serveur puis de faire un "chown" du HomeDir. Si le compte est correctement créé sur le serveur, au prochain login tu auras un "network account".
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
-- Mag'
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le
serveur et un en local, ayant tout deux le même username, alors c'est le
compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils
n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte
local, (faut être logué avec un autre compte) de vérifier que le client
est correctement connecté au serveur puis de faire un "chown" du
HomeDir.
Si le compte est correctement créé sur le serveur, au prochain login tu
auras un "network account".
Si j'ai bien compris, on aura fait disparaître le compte local et on
l'aura remplacer par le compte en réseau. Au passage, ce sera totalement
transparent pour l'utilisateur puisque son "Home" sera bien exactement
le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux"
? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans
ce genre de manipulation ?
Autre question, mon idée naïve serait un jour d'avoir des profils
itinérants. Mais en reprenant celui existant sur la machine principale
de chaque utilisateur au moment du transfert. Est-ce que je peux adapter
cette manip en copiant le "Home" sur mon serveur avant de passer en
itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout
casser, je peux donc me permettre d'y passer du temps ! :-)
Si comme dans ce que tu décris, tu as deux comptes différents, un sur le serveur et un en local, ayant tout deux le même username, alors c'est le compte local qui sera utilisé. Et ce sont bien 2 comptes différents, ils n'ont pas le même "GeneratedUID"
La solution serait d'effacer dans la base netinfo du client le compte local, (faut être logué avec un autre compte) de vérifier que le client est correctement connecté au serveur puis de faire un "chown" du HomeDir. Si le compte est correctement créé sur le serveur, au prochain login tu auras un "network account".
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
-- Mag'
Nicolas.MICHEL
MagalieJ wrote:
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Bin dans tous les cas, quoi que tu fasse, un bon backup est mère de sureté. A présent j'ai fréquement effacé un compte dans netinfo sans soucis. Mais je suis à l'aise avec ce genre de choses et peut-être que tu vas buter sur des questions qui me semblent évidentes. A tester donc.
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
Les profils itinérants sont intéressants lorsque tu veux centraliser les backup ou lorsque tu as des utilisateurs nomades qui peuvent ainssi retrouver leures données lorsqu'ils changent de machine. Mais je ne mettrais pas ça en place avant d'avoir un serveur qui tourne impécablement, qui a des sauvegardes béton, qu'il n'y a plus de conflicts dns et que tous les comptes sont managés sans soucis depuis le serveur. Après, je ne sais pas exactement comment ça se passe, j'ai jamais mis ça en prod.
-- Nicolas
MagalieJ <mag@lery.nom.fr> wrote:
Si j'ai bien compris, on aura fait disparaître le compte local et on
l'aura remplacer par le compte en réseau. Au passage, ce sera totalement
transparent pour l'utilisateur puisque son "Home" sera bien exactement
le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux"
? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans
ce genre de manipulation ?
Bin dans tous les cas, quoi que tu fasse, un bon backup est mère de
sureté.
A présent j'ai fréquement effacé un compte dans netinfo sans soucis.
Mais je suis à l'aise avec ce genre de choses et peut-être que tu vas
buter sur des questions qui me semblent évidentes.
A tester donc.
Autre question, mon idée naïve serait un jour d'avoir des profils
itinérants. Mais en reprenant celui existant sur la machine principale
de chaque utilisateur au moment du transfert. Est-ce que je peux adapter
cette manip en copiant le "Home" sur mon serveur avant de passer en
itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout
casser, je peux donc me permettre d'y passer du temps ! :-)
Les profils itinérants sont intéressants lorsque tu veux centraliser les
backup ou lorsque tu as des utilisateurs nomades qui peuvent ainssi
retrouver leures données lorsqu'ils changent de machine.
Mais je ne mettrais pas ça en place avant d'avoir un serveur qui tourne
impécablement, qui a des sauvegardes béton, qu'il n'y a plus de
conflicts dns et que tous les comptes sont managés sans soucis depuis le
serveur.
Après, je ne sais pas exactement comment ça se passe, j'ai jamais mis ça
en prod.
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Bin dans tous les cas, quoi que tu fasse, un bon backup est mère de sureté. A présent j'ai fréquement effacé un compte dans netinfo sans soucis. Mais je suis à l'aise avec ce genre de choses et peut-être que tu vas buter sur des questions qui me semblent évidentes. A tester donc.
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
Les profils itinérants sont intéressants lorsque tu veux centraliser les backup ou lorsque tu as des utilisateurs nomades qui peuvent ainssi retrouver leures données lorsqu'ils changent de machine. Mais je ne mettrais pas ça en place avant d'avoir un serveur qui tourne impécablement, qui a des sauvegardes béton, qu'il n'y a plus de conflicts dns et que tous les comptes sont managés sans soucis depuis le serveur. Après, je ne sais pas exactement comment ça se passe, j'ai jamais mis ça en prod.
-- Nicolas
laurent.pertois
MagalieJ wrote:
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Euh, bien remettre le même UID à l'utilisateur "réseau". Et si on a utilisé les ACLs c'est plus embêtant, il faut lui remettre le même GUID.
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
Mmmm, va falloir que tu testes. Déjà les profils itinérants sont appeles "Comptes mobiles" dans la langue de Mac OS X Server.
Après, je recommande de faire un essai sur une machine qui ne craint rien et des données bien sauvegardées ou, une fois de plus, qui ne craignent rien.
Copie le dossier utilisateur, crée l'utilisateur sur le serveur, attribue-lui son home, change les droits sur ce dossier. Détruis le compte local sur la machine d'origine, connexion LDAP sur le client, ouverture d'une session compte mobile, synchro. Et dis-nous.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
MagalieJ <mag@lery.nom.fr> wrote:
Si j'ai bien compris, on aura fait disparaître le compte local et on
l'aura remplacer par le compte en réseau. Au passage, ce sera totalement
transparent pour l'utilisateur puisque son "Home" sera bien exactement
le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux"
? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans
ce genre de manipulation ?
Euh, bien remettre le même UID à l'utilisateur "réseau". Et si on a
utilisé les ACLs c'est plus embêtant, il faut lui remettre le même GUID.
Autre question, mon idée naïve serait un jour d'avoir des profils
itinérants. Mais en reprenant celui existant sur la machine principale
de chaque utilisateur au moment du transfert. Est-ce que je peux adapter
cette manip en copiant le "Home" sur mon serveur avant de passer en
itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout
casser, je peux donc me permettre d'y passer du temps ! :-)
Mmmm, va falloir que tu testes. Déjà les profils itinérants sont appeles
"Comptes mobiles" dans la langue de Mac OS X Server.
Après, je recommande de faire un essai sur une machine qui ne craint
rien et des données bien sauvegardées ou, une fois de plus, qui ne
craignent rien.
Copie le dossier utilisateur, crée l'utilisateur sur le serveur,
attribue-lui son home, change les droits sur ce dossier. Détruis le
compte local sur la machine d'origine, connexion LDAP sur le client,
ouverture d'une session compte mobile, synchro. Et dis-nous.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Si j'ai bien compris, on aura fait disparaître le compte local et on l'aura remplacer par le compte en réseau. Au passage, ce sera totalement transparent pour l'utilisateur puisque son "Home" sera bien exactement le même. Est-ce qu'il peut cependant y avoir des "dommages collatéraux" ? Ou des choses qu'il vaut mieux bien vérifier avant de se lancer dans ce genre de manipulation ?
Euh, bien remettre le même UID à l'utilisateur "réseau". Et si on a utilisé les ACLs c'est plus embêtant, il faut lui remettre le même GUID.
Autre question, mon idée naïve serait un jour d'avoir des profils itinérants. Mais en reprenant celui existant sur la machine principale de chaque utilisateur au moment du transfert. Est-ce que je peux adapter cette manip en copiant le "Home" sur mon serveur avant de passer en itinérant ? Petite précision : je dois avoir 5 utilisateurs à tout casser, je peux donc me permettre d'y passer du temps ! :-)
Mmmm, va falloir que tu testes. Déjà les profils itinérants sont appeles "Comptes mobiles" dans la langue de Mac OS X Server.
Après, je recommande de faire un essai sur une machine qui ne craint rien et des données bien sauvegardées ou, une fois de plus, qui ne craignent rien.
Copie le dossier utilisateur, crée l'utilisateur sur le serveur, attribue-lui son home, change les droits sur ce dossier. Détruis le compte local sur la machine d'origine, connexion LDAP sur le client, ouverture d'une session compte mobile, synchro. Et dis-nous.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
