Est-ce que quelqu'un a une expérience de déploiement de MacOSX en postes
banalisés sur une grosse base d'utilisateurs, avec les répertoires
d'accueils partagés ?
Autrement dit l'authentification est faite via un serveur ldap (posixAccount) par
exemple et les répertoires utilisateurs sont sur un serveur (nfs ou
afp), mais préexistants et contenant des données.
Est-ce que les répertoires nécessaires à MacOSX (Library notament)
sont créés au vol ? Est-ce qu'il faut des procédures spéciales ?
nfs fonctionne-t-il ? Pour afp il faut pouvoir faire passer
l'identification..
Je sais que am-utils (notre automonteur favori) est porté sous MacOSX.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Le roaming profile repose sur une technologie qui recopie à la connexion le profil sur le disque local, puis le recopie dans l'autre sens à la déconnexion. Un répertoire partagé on se contente de faire un montage réseau du disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-) Marrant que ça soit une prise de tête pareille pour faire un truc qui intellectuellement semble très simple. -- Nina
On Fri, 29 Sep 2006 19:20:01 +0200, filh@filh.orgie (FiLH) wrote:
Le roaming profile repose sur une technologie qui recopie à la connexion
le profil sur le disque local, puis le recopie dans l'autre sens à la
déconnexion.
Un répertoire partagé on se contente de faire un montage réseau du
disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-)
Marrant que ça soit une prise de tête pareille pour faire un truc qui
intellectuellement semble très simple.
--
Nina
Le roaming profile repose sur une technologie qui recopie à la connexion le profil sur le disque local, puis le recopie dans l'autre sens à la déconnexion. Un répertoire partagé on se contente de faire un montage réseau du disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-) Marrant que ça soit une prise de tête pareille pour faire un truc qui intellectuellement semble très simple. -- Nina
filh
Nina Popravka wrote:
On Fri, 29 Sep 2006 19:20:01 +0200, (FiLH) wrote:
Le roaming profile repose sur une technologie qui recopie à la connexion le profil sur le disque local, puis le recopie dans l'autre sens à la déconnexion. Un répertoire partagé on se contente de faire un montage réseau du disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-) Marrant que ça soit une prise de tête pareille pour faire un truc qui intellectuellement semble très simple.
D'autant que bon... dans le profil il y a quand même les caches IE par exemple :(
En fait c'est un affreux patch sur une conception totalement foireuse. Sur un PC les données utilisateurs sont réparties un peu partout. Et sur MacOS9 c'était pas trop non plus, notamment les préférences systèmes.
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire des machines qui s'installent et se gèrent naturellement en réseau.
Ce sont les premier qui avaient des installs réseau je crois, les premiers qui permettait de partager tout ou partie d'un arborescence unix tout en sachant gérer les patch dessus.
Quoi qu'il parait qu'apollo était top du top.
Maintenant à l'époque une prise réseau ethernet c'était pas donné, et donc ça restreignait pas mal le nombre de constructeurs qui pouvaient expérimenter.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka <Nina@nospam> wrote:
On Fri, 29 Sep 2006 19:20:01 +0200, filh@filh.orgie (FiLH) wrote:
Le roaming profile repose sur une technologie qui recopie à la connexion
le profil sur le disque local, puis le recopie dans l'autre sens à la
déconnexion.
Un répertoire partagé on se contente de faire un montage réseau du
disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-)
Marrant que ça soit une prise de tête pareille pour faire un truc qui
intellectuellement semble très simple.
D'autant que bon... dans le profil il y a quand même les caches IE par
exemple :(
En fait c'est un affreux patch sur une conception totalement foireuse.
Sur un PC les données utilisateurs sont réparties un peu partout.
Et sur MacOS9 c'était pas trop non plus, notamment les préférences
systèmes.
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire
des machines qui s'installent et se gèrent naturellement en réseau.
Ce sont les premier qui avaient des installs réseau je crois, les
premiers qui permettait de partager tout ou partie d'un arborescence
unix tout en sachant gérer les patch dessus.
Quoi qu'il parait qu'apollo était top du top.
Maintenant à l'époque une prise réseau ethernet c'était pas donné, et
donc ça restreignait pas mal le nombre de constructeurs qui pouvaient
expérimenter.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le roaming profile repose sur une technologie qui recopie à la connexion le profil sur le disque local, puis le recopie dans l'autre sens à la déconnexion. Un répertoire partagé on se contente de faire un montage réseau du disque et le client utilise ce dont il a besoin.
Vu, et c'est effectivement plus intelligent :-) Marrant que ça soit une prise de tête pareille pour faire un truc qui intellectuellement semble très simple.
D'autant que bon... dans le profil il y a quand même les caches IE par exemple :(
En fait c'est un affreux patch sur une conception totalement foireuse. Sur un PC les données utilisateurs sont réparties un peu partout. Et sur MacOS9 c'était pas trop non plus, notamment les préférences systèmes.
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire des machines qui s'installent et se gèrent naturellement en réseau.
Ce sont les premier qui avaient des installs réseau je crois, les premiers qui permettait de partager tout ou partie d'un arborescence unix tout en sachant gérer les patch dessus.
Quoi qu'il parait qu'apollo était top du top.
Maintenant à l'époque une prise réseau ethernet c'était pas donné, et donc ça restreignait pas mal le nombre de constructeurs qui pouvaient expérimenter.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka
On Fri, 29 Sep 2006 20:12:37 +0200, (FiLH) wrote:
En fait c'est un affreux patch sur une conception totalement foireuse. Sur un PC les données utilisateurs sont réparties un peu partout. Et sur MacOS9 c'était pas trop non plus, notamment les préférences systèmes. MacOSX fout bien son bronx aussi...
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire des machines qui s'installent et se gèrent naturellement en réseau. Je pense surtout que tant qu'il n'y a pas une norme sur ce qui doit
être où, on n'est pas rendus. Et comme c'est pas demain la veille...
Quoi qu'il parait qu'apollo était top du top. Maintenant à l'époque une prise réseau ethernet c'était pas donné, et donc ça restreignait pas mal le nombre de constructeurs qui pouvaient expérimenter. Et on faisait moins de choses en réseau avec plein de softs exotiques
et des boîtes à lettres de 2 Go. O tempora, o mores, etc etc etc :-)))))) -- Nina
On Fri, 29 Sep 2006 20:12:37 +0200, filh@filh.orgie (FiLH) wrote:
En fait c'est un affreux patch sur une conception totalement foireuse.
Sur un PC les données utilisateurs sont réparties un peu partout.
Et sur MacOS9 c'était pas trop non plus, notamment les préférences
systèmes.
MacOSX fout bien son bronx aussi...
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire
des machines qui s'installent et se gèrent naturellement en réseau.
Je pense surtout que tant qu'il n'y a pas une norme sur ce qui doit
être où, on n'est pas rendus. Et comme c'est pas demain la veille...
Quoi qu'il parait qu'apollo était top du top.
Maintenant à l'époque une prise réseau ethernet c'était pas donné, et
donc ça restreignait pas mal le nombre de constructeurs qui pouvaient
expérimenter.
Et on faisait moins de choses en réseau avec plein de softs exotiques
et des boîtes à lettres de 2 Go.
O tempora, o mores, etc etc etc :-))))))
--
Nina
En fait c'est un affreux patch sur une conception totalement foireuse. Sur un PC les données utilisateurs sont réparties un peu partout. Et sur MacOS9 c'était pas trop non plus, notamment les préférences systèmes. MacOSX fout bien son bronx aussi...
Honnetement il n'y a que SUN à ma connaissance qui sache vraiment faire des machines qui s'installent et se gèrent naturellement en réseau. Je pense surtout que tant qu'il n'y a pas une norme sur ce qui doit
être où, on n'est pas rendus. Et comme c'est pas demain la veille...
Quoi qu'il parait qu'apollo était top du top. Maintenant à l'époque une prise réseau ethernet c'était pas donné, et donc ça restreignait pas mal le nombre de constructeurs qui pouvaient expérimenter. Et on faisait moins de choses en réseau avec plein de softs exotiques
et des boîtes à lettres de 2 Go. O tempora, o mores, etc etc etc :-)))))) -- Nina
laurent.pertois
Xavier wrote:
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc. D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-)
C'est quand même étrange, vous êtes combien ?
Je connais des écoles en Suisse qui ont ça avec plusieurs dizaines d'étudiants.
Et tous arrivent à s'authentifier, ce n'est que le montage auto, le serveur Software Update qui ne marchent pas.
Mmmmm, y a un truc étrange, il faudrait fouiller.
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes les extensions MCX qui ne sont tout simplement pas envisageables sur un LDAP standard sans migraines.
Mais si, tu étends le schéma avec le fichier de schéma d'Apple. Il est dispo même sur un client dans :
Une fois cela fait, le Workgroup Manager, lancé sur un client correctement et intégralement mappé, sait administrer les champs Apple sur le LDAP tierce-partie pour y inscrire les bonnes valeurs qui vont bien.
De toutes façons, si tu le fais faire ça te coûtera deux yeux, alors qu'un Tiger Serveur ne t'en coûtera qu'un :-)
Ca, je plussoie.
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB les autorisations (ACL sur Tiger) et les forks.
Je plussoie encore.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite pas.
Et là, je n'arrête pas de plussoyer.
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5 et pas encore de DualCore...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Xavier <xavier@groumpf.org> wrote:
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se
connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc.
D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-)
C'est quand même étrange, vous êtes combien ?
Je connais des écoles en Suisse qui ont ça avec plusieurs dizaines
d'étudiants.
Et tous arrivent à s'authentifier, ce n'est que le montage auto, le
serveur Software Update qui ne marchent pas.
Mmmmm, y a un truc étrange, il faudrait fouiller.
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes
les extensions MCX qui ne sont tout simplement pas envisageables sur un
LDAP standard sans migraines.
Mais si, tu étends le schéma avec le fichier de schéma d'Apple. Il est
dispo même sur un client dans :
Une fois cela fait, le Workgroup Manager, lancé sur un client
correctement et intégralement mappé, sait administrer les champs Apple
sur le LDAP tierce-partie pour y inscrire les bonnes valeurs qui vont
bien.
De toutes façons, si tu le fais faire ça te coûtera deux yeux, alors
qu'un Tiger Serveur ne t'en coûtera qu'un :-)
Ca, je plussoie.
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB
les autorisations (ACL sur Tiger) et les forks.
Je plussoie encore.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite
pas.
Et là, je n'arrête pas de plussoyer.
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5
et pas encore de DualCore...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc. D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-)
C'est quand même étrange, vous êtes combien ?
Je connais des écoles en Suisse qui ont ça avec plusieurs dizaines d'étudiants.
Et tous arrivent à s'authentifier, ce n'est que le montage auto, le serveur Software Update qui ne marchent pas.
Mmmmm, y a un truc étrange, il faudrait fouiller.
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes les extensions MCX qui ne sont tout simplement pas envisageables sur un LDAP standard sans migraines.
Mais si, tu étends le schéma avec le fichier de schéma d'Apple. Il est dispo même sur un client dans :
Une fois cela fait, le Workgroup Manager, lancé sur un client correctement et intégralement mappé, sait administrer les champs Apple sur le LDAP tierce-partie pour y inscrire les bonnes valeurs qui vont bien.
De toutes façons, si tu le fais faire ça te coûtera deux yeux, alors qu'un Tiger Serveur ne t'en coûtera qu'un :-)
Ca, je plussoie.
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB les autorisations (ACL sur Tiger) et les forks.
Je plussoie encore.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite pas.
Et là, je n'arrête pas de plussoyer.
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5 et pas encore de DualCore...
-- 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
Xavier wrote:
Je viens de lire l'échange, et d'expérience, je peux te dire que tu t'en sortiras difficilement avec un MacOSX Serveur, et que ce n'est même pas la peine d'essayer avec un LDAP non-Apple.
Je l'ai mis en place sur un serveur OpenLDAP hébergé par une Debian, les homes étaient même sur la Debian, partagés par netatalk 2.x. Ca fonctionne.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Xavier <xavier@groumpf.org> wrote:
Je viens de lire l'échange, et d'expérience, je peux te dire que tu t'en
sortiras difficilement avec un MacOSX Serveur, et que ce n'est même pas
la peine d'essayer avec un LDAP non-Apple.
Je l'ai mis en place sur un serveur OpenLDAP hébergé par une Debian, les
homes étaient même sur la Debian, partagés par netatalk 2.x. Ca
fonctionne.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Je viens de lire l'échange, et d'expérience, je peux te dire que tu t'en sortiras difficilement avec un MacOSX Serveur, et que ce n'est même pas la peine d'essayer avec un LDAP non-Apple.
Je l'ai mis en place sur un serveur OpenLDAP hébergé par une Debian, les homes étaient même sur la Debian, partagés par netatalk 2.x. Ca fonctionne.
-- 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
FiLH wrote:
Pour l'instant l'idée serait d'avoir les macs direct clients du ldap. Mais est-ce possible ?
Oui, ça nécessite de jouer un peu avec les mappages, mais c'est faisable.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
FiLH <filh@filh.orgie> wrote:
Pour l'instant l'idée serait d'avoir les macs direct clients du ldap.
Mais est-ce possible ?
Oui, ça nécessite de jouer un peu avec les mappages, mais c'est
faisable.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Pour l'instant l'idée serait d'avoir les macs direct clients du ldap. Mais est-ce possible ?
Oui, ça nécessite de jouer un peu avec les mappages, mais c'est faisable.
-- 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
FiLH wrote:
Xavier wrote:
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc.
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
Bah, OpenDirectory a _besoin_ d'un DNS bien configuré, surtout pour Kerberos. Le DHCP permet, moyennant ses extensions LDAP, de diffuser l'adresse du serveur LDAP présent sur le réseau, du coup le client Mac OS X n'a pas besoin d'être configuré en dur. Cela dit, si on peut le faire, c'est souvent préférable.
D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-) Et tous arrivent à s'authentifier, ce n'est que le montage auto, le serveur Software Update qui ne marchent pas.
Il semble quand même que ça marche chez des gens non ?
J'en connais, oui :)
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes les extensions MCX qui ne sont tout simplement pas envisageables sur un LDAP standard sans migraines.
Bah... chuis pas migraineux :)
Heureux homme :-/
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB les autorisations (ACL sur Tiger) et les forks.
J'ai déjà un serveur AFP. C'est une solution qui ne me dérange pas plus que ça (sauf que bon faudra identifier).
Ca, l'authentification, Mac OS X s'en charge, à l'ouverture de session il monte le volume avec les login/mdp de l'utilisateur qui ouvre la session.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite pas.
Le pb n'est pas le serveur. Le pb c'est : - utiliser la même base utilisateurs/mdp
Ca, on sait faire. En fait, si on ne veut pas étendre le schéma LDAP existant, on fait ce qu'on appelle un triangle magique, on a le LDAP d'origine pour l'authentification et un OpenDirectory pour gérer les particularités Apple qui nécessitent cette extension du schéma.
- partager les répertoires d'accueil : on ne peut pas se permettre de doubler les répertoires, d'abord parce que les utilisateurs ne seront pas content et ensuite faut douber nos baies san :(
Pas forcément besoin de les doubler, pas de soucis.
- on ne peut pas par ailleurs sur chaque mac client créer un répertoire par utilisateur (on en a 1200 des users)
Ca également.
Bon si je ne peux éviter de monter un OD qui serait client de notre annuaire ldap on fera comme ça.
Ca peut se faire.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
FiLH <filh@filh.orgie> wrote:
Xavier <xavier@groumpf.org> wrote:
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se
connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc.
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
Bah, OpenDirectory a _besoin_ d'un DNS bien configuré, surtout pour
Kerberos. Le DHCP permet, moyennant ses extensions LDAP, de diffuser
l'adresse du serveur LDAP présent sur le réseau, du coup le client Mac
OS X n'a pas besoin d'être configuré en dur. Cela dit, si on peut le
faire, c'est souvent préférable.
D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-)
Et tous arrivent à s'authentifier, ce n'est que le montage auto, le
serveur Software Update qui ne marchent pas.
Il semble quand même que ça marche chez des gens non ?
J'en connais, oui :)
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes
les extensions MCX qui ne sont tout simplement pas envisageables sur un
LDAP standard sans migraines.
Bah... chuis pas migraineux :)
Heureux homme :-/
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB
les autorisations (ACL sur Tiger) et les forks.
J'ai déjà un serveur AFP. C'est une solution qui ne me dérange pas plus
que ça (sauf que bon faudra identifier).
Ca, l'authentification, Mac OS X s'en charge, à l'ouverture de session
il monte le volume avec les login/mdp de l'utilisateur qui ouvre la
session.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite
pas.
Le pb n'est pas le serveur. Le pb c'est :
- utiliser la même base utilisateurs/mdp
Ca, on sait faire. En fait, si on ne veut pas étendre le schéma LDAP
existant, on fait ce qu'on appelle un triangle magique, on a le LDAP
d'origine pour l'authentification et un OpenDirectory pour gérer les
particularités Apple qui nécessitent cette extension du schéma.
- partager les répertoires d'accueil : on ne peut pas se permettre de
doubler les répertoires, d'abord parce que les utilisateurs ne seront
pas content et ensuite faut douber nos baies san :(
Pas forcément besoin de les doubler, pas de soucis.
- on ne peut pas par ailleurs sur chaque mac client créer un répertoire
par utilisateur (on en a 1200 des users)
Ca également.
Bon si je ne peux éviter de monter un OD qui serait client de notre
annuaire ldap on fera comme ça.
Ca peut se faire.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
J'ai un Tiger Serveur au boulot. Les 3/4 des Macs n'arrivent pas à se connecter sur la base OD, malgré les réglages DNS et DHCP ad-hoc.
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
Bah, OpenDirectory a _besoin_ d'un DNS bien configuré, surtout pour Kerberos. Le DHCP permet, moyennant ses extensions LDAP, de diffuser l'adresse du serveur LDAP présent sur le réseau, du coup le client Mac OS X n'a pas besoin d'être configuré en dur. Cela dit, si on peut le faire, c'est souvent préférable.
D'ailleurs, la preuve que ça marche, 1/4 des machines y arrivent :-) Et tous arrivent à s'authentifier, ce n'est que le montage auto, le serveur Software Update qui ne marchent pas.
Il semble quand même que ça marche chez des gens non ?
J'en connais, oui :)
Il y a des particularités du schéma LDAP d'Apple, en particulier toutes les extensions MCX qui ne sont tout simplement pas envisageables sur un LDAP standard sans migraines.
Bah... chuis pas migraineux :)
Heureux homme :-/
Autre avantage de MacOSX Serveur : AFP gère bien mieux que NFS ou SMB les autorisations (ACL sur Tiger) et les forks.
J'ai déjà un serveur AFP. C'est une solution qui ne me dérange pas plus que ça (sauf que bon faudra identifier).
Ca, l'authentification, Mac OS X s'en charge, à l'ouverture de session il monte le volume avec les login/mdp de l'utilisateur qui ouvre la session.
Et tu dis toi même qu'un petit XServe n'est pas si cher, alors n'hésite pas.
Le pb n'est pas le serveur. Le pb c'est : - utiliser la même base utilisateurs/mdp
Ca, on sait faire. En fait, si on ne veut pas étendre le schéma LDAP existant, on fait ce qu'on appelle un triangle magique, on a le LDAP d'origine pour l'authentification et un OpenDirectory pour gérer les particularités Apple qui nécessitent cette extension du schéma.
- partager les répertoires d'accueil : on ne peut pas se permettre de doubler les répertoires, d'abord parce que les utilisateurs ne seront pas content et ensuite faut douber nos baies san :(
Pas forcément besoin de les doubler, pas de soucis.
- on ne peut pas par ailleurs sur chaque mac client créer un répertoire par utilisateur (on en a 1200 des users)
Ca également.
Bon si je ne peux éviter de monter un OD qui serait client de notre annuaire ldap on fera comme ça.
Ca peut se faire.
-- 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
Nicolas MICHEL wrote:
Va falloir voir..
Il y avait un pdf de MacTroll sur http://www.afp548.com à propos d'intégration AD/OD. Sauf que je ne retrouve plus le lien. Si tu veux que je t'envoies le pdf tu peux me faire un mail à "nicolas point michel at isrec point ch" par exemple.
Ah, dans ce cas ça ne doit pas être trop compliqué d'ajouter un bout de schéma, non ?
Ca se fait.
Bon, sur un truc en prod c'est toujours délicat mais tu as au moins les fichier de Apple tout prêts.
Faut tester.
Enfin ça demande un admin ldap ouvert et compréhensif, ce qui n'est pas forcément le cas :-/
Marrant, pour du LDAP, je rencontre souvent des admins compréhensifs car ils maîtrisent le truc pour l'avoir quand même un peu monté à la main. Dans le cas d'un AD, c'est beaucoup plus rare, mais je les comprend, c'est délicat comme petite bête.
-- 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 <Nicolas.MICHEL@BonBon.net> wrote:
Va falloir voir..
Il y avait un pdf de MacTroll sur http://www.afp548.com à propos
d'intégration AD/OD. Sauf que je ne retrouve plus le lien.
Si tu veux que je t'envoies le pdf tu peux me faire un mail à
"nicolas point michel at isrec point ch" par exemple.
Ah, dans ce cas ça ne doit pas être trop compliqué d'ajouter un bout de
schéma, non ?
Ca se fait.
Bon, sur un truc en prod c'est toujours délicat mais tu as au moins les
fichier de Apple tout prêts.
Faut tester.
Enfin ça demande un admin ldap ouvert et compréhensif, ce qui n'est pas
forcément le cas :-/
Marrant, pour du LDAP, je rencontre souvent des admins compréhensifs car
ils maîtrisent le truc pour l'avoir quand même un peu monté à la main.
Dans le cas d'un AD, c'est beaucoup plus rare, mais je les comprend,
c'est délicat comme petite bête.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Il y avait un pdf de MacTroll sur http://www.afp548.com à propos d'intégration AD/OD. Sauf que je ne retrouve plus le lien. Si tu veux que je t'envoies le pdf tu peux me faire un mail à "nicolas point michel at isrec point ch" par exemple.
Ah, dans ce cas ça ne doit pas être trop compliqué d'ajouter un bout de schéma, non ?
Ca se fait.
Bon, sur un truc en prod c'est toujours délicat mais tu as au moins les fichier de Apple tout prêts.
Faut tester.
Enfin ça demande un admin ldap ouvert et compréhensif, ce qui n'est pas forcément le cas :-/
Marrant, pour du LDAP, je rencontre souvent des admins compréhensifs car ils maîtrisent le truc pour l'avoir quand même un peu monté à la main. Dans le cas d'un AD, c'est beaucoup plus rare, mais je les comprend, c'est délicat comme petite bête.
-- 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
Xavier wrote:
FiLH wrote:
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
C'est le mantra sur f.c.o.mac-osx.serveur :-)
Tu exagères, on peut vivre sans le DHCP :)
Par contre, pour un OD, si le DNS est mal configuré, c'est souvent cause de suicide...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Xavier <xavier@groumpf.org> wrote:
FiLH <filh@filh.orgie> wrote:
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
C'est le mantra sur f.c.o.mac-osx.serveur :-)
Tu exagères, on peut vivre sans le DHCP :)
Par contre, pour un OD, si le DNS est mal configuré, c'est souvent cause
de suicide...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Heu... c'est quoi la connexion entre OD, DNS et DHCP ?
C'est le mantra sur f.c.o.mac-osx.serveur :-)
Tu exagères, on peut vivre sans le DHCP :)
Par contre, pour un OD, si le DNS est mal configuré, c'est souvent cause de suicide...
-- 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
Xavier wrote:
Laurent Pertois wrote:
Mmmmm, y a un truc étrange, il faudrait fouiller.
J'ai pas le temps de m'en occuper. On ne se sert que du serveur AFP, donc c'est pas grave.
Mais c'est un peu bête :)
Mais le message est assez clair sur le client (je viens d'aller voir à l'instant ):
Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Can't retrieve server mappings from search base of <injep.fr>. Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Cannot retrieve server mappings at this time. Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn: Server Mappings for [ldap.injep.fr] LDAP server not found. Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn: [ldap.injep.fr] LDAP server config not updated with server mappings due to server mappings error.
C'est un Tiger Serveur sans aucune fioriture, et le message est le même que le serveur soit mis en dur ou fourni par DHCP
Mmmm, il n'arrive pas à lire les mappages, la base de recherche LDAP est la bonne dans le DHCP comparée à celle du serveur ? (il y a eu un changement en 10.4, attention)
et sur un client, en remplaçant 127.0.0.1 par l'adresse du serveur telle que déclarée dans le DHCP. En cas de doutes, entre dans dscl en mode interactif :
$ dscl localhost
Après, tu regardes ce qu'il y a avec "ls", tu te déplaces avec "cd" et tu affiches le contenu d'une entrée avec "read" (ou éventuellement avec "cat"). La lecture du man de dscl est très instructive et c'est un outil qui aide énormément en cas de soucis avec la structure OpenDirectory de Mac OS X.
(Apple recommande expréssément d'utiliser DHCP pour les clients)
Ah ?
[... snip plein de choses intéressantes ...]
:-)
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5 et pas encore de DualCore...
Toujours aussi lamentable dans ce domaine...
Ah ben, ça plaît aux actionnaires, tu penses bien, pas de stock à gérer, rien à refourguer sur le refurb :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
J'ai pas le temps de m'en occuper. On ne se sert que du serveur AFP,
donc c'est pas grave.
Mais c'est un peu bête :)
Mais le message est assez clair sur le client (je viens d'aller voir à
l'instant ):
Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Can't
retrieve server mappings from search base of <injep.fr>.
Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Cannot
retrieve server mappings at this time.
Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn: Server
Mappings for [ldap.injep.fr] LDAP server not found.
Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn:
[ldap.injep.fr] LDAP server config not updated with server
mappings due to server mappings error.
C'est un Tiger Serveur sans aucune fioriture, et le message est le même
que le serveur soit mis en dur ou fourni par DHCP
Mmmm, il n'arrive pas à lire les mappages, la base de recherche LDAP est
la bonne dans le DHCP comparée à celle du serveur ? (il y a eu un
changement en 10.4, attention)
et sur un client, en remplaçant 127.0.0.1 par l'adresse du serveur telle
que déclarée dans le DHCP. En cas de doutes, entre dans dscl en mode
interactif :
$ dscl localhost
Après, tu regardes ce qu'il y a avec "ls", tu te déplaces avec "cd" et
tu affiches le contenu d'une entrée avec "read" (ou éventuellement avec
"cat"). La lecture du man de dscl est très instructive et c'est un outil
qui aide énormément en cas de soucis avec la structure OpenDirectory de
Mac OS X.
(Apple recommande
expréssément d'utiliser DHCP pour les clients)
Ah ?
[... snip plein de choses intéressantes ...]
:-)
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5
et pas encore de DualCore...
Toujours aussi lamentable dans ce domaine...
Ah ben, ça plaît aux actionnaires, tu penses bien, pas de stock à gérer,
rien à refourguer sur le refurb :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
J'ai pas le temps de m'en occuper. On ne se sert que du serveur AFP, donc c'est pas grave.
Mais c'est un peu bête :)
Mais le message est assez clair sur le client (je viens d'aller voir à l'instant ):
Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Can't retrieve server mappings from search base of <injep.fr>. Sep 30 00:00:01 xx-xxx DirectoryService[319]: CLDAPNode::SafeOpen Cannot retrieve server mappings at this time. Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn: Server Mappings for [ldap.injep.fr] LDAP server not found. Sep 30 02:13:43 xx-xxx DirectoryService[319]: DSLDAPv3PlugIn: [ldap.injep.fr] LDAP server config not updated with server mappings due to server mappings error.
C'est un Tiger Serveur sans aucune fioriture, et le message est le même que le serveur soit mis en dur ou fourni par DHCP
Mmmm, il n'arrive pas à lire les mappages, la base de recherche LDAP est la bonne dans le DHCP comparée à celle du serveur ? (il y a eu un changement en 10.4, attention)
et sur un client, en remplaçant 127.0.0.1 par l'adresse du serveur telle que déclarée dans le DHCP. En cas de doutes, entre dans dscl en mode interactif :
$ dscl localhost
Après, tu regardes ce qu'il y a avec "ls", tu te déplaces avec "cd" et tu affiches le contenu d'une entrée avec "read" (ou éventuellement avec "cat"). La lecture du man de dscl est très instructive et c'est un outil qui aide énormément en cas de soucis avec la structure OpenDirectory de Mac OS X.
(Apple recommande expréssément d'utiliser DHCP pour les clients)
Ah ?
[... snip plein de choses intéressantes ...]
:-)
Sauf qu'en ce moment les Xserve sont indisponibles à l'achat, plus de G5 et pas encore de DualCore...
Toujours aussi lamentable dans ce domaine...
Ah ben, ça plaît aux actionnaires, tu penses bien, pas de stock à gérer, rien à refourguer sur le refurb :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
