Anonyme wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
Anonyme <jayce@mosx.org> wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
Anonyme wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
FiLH wrote:> C'est tout à fait possible de tout faire en ligne de commande... Mais
> alors j'ai une question bête... Quel est l'intérêt de Mac OS X Server
> alors par rapport à un Linux ?
Heu... deux trois choses :)
Lesquelles ? Si c'est pour tout faire sans interface graphique,
vraiment, j'aimerai bien connaître les deux/trois interêts
supplémentaires de Mac OS X Server...
FiLH <filh@filh.orgie> wrote:
> C'est tout à fait possible de tout faire en ligne de commande... Mais
> alors j'ai une question bête... Quel est l'intérêt de Mac OS X Server
> alors par rapport à un Linux ?
Heu... deux trois choses :)
Lesquelles ? Si c'est pour tout faire sans interface graphique,
vraiment, j'aimerai bien connaître les deux/trois interêts
supplémentaires de Mac OS X Server...
FiLH wrote:> C'est tout à fait possible de tout faire en ligne de commande... Mais
> alors j'ai une question bête... Quel est l'intérêt de Mac OS X Server
> alors par rapport à un Linux ?
Heu... deux trois choses :)
Lesquelles ? Si c'est pour tout faire sans interface graphique,
vraiment, j'aimerai bien connaître les deux/trois interêts
supplémentaires de Mac OS X Server...
Laurent Pertois wrote:Anonyme wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Laurent Pertois <laurent.pertois@alussinan.org> wrote:
Anonyme <jayce@mosx.org> wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Laurent Pertois wrote:Anonyme wrote:
> Lesquelles ? Si c'est pour tout faire sans interface graphique,
> vraiment, j'aimerai bien connaître les deux/trois interêts
> supplémentaires de Mac OS X Server...
mcx ?
Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
(Anonyme) writes:
> Laurent Pertois wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
jayce@mosx.org (Anonyme) writes:
> Laurent Pertois <laurent.pertois@alussinan.org> wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
(Anonyme) writes:
> Laurent Pertois wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
FiLH wrote:(Anonyme) writes:
> Laurent Pertois wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Oui et non.
On peut étendre le schéma pour intégrer les attributs Apple qui
contiennent les mcx. Mais le plus simple est encore de faire un triangle
magique.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
faut aussi bien mapper pour qu'il trouve les éléments à côté.
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
Ca, c'est la version compliquée :-)
FiLH <filh@filh.org> wrote:
jayce@mosx.org (Anonyme) writes:
> Laurent Pertois <laurent.pertois@alussinan.org> wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Oui et non.
On peut étendre le schéma pour intégrer les attributs Apple qui
contiennent les mcx. Mais le plus simple est encore de faire un triangle
magique.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
faut aussi bien mapper pour qu'il trouve les éléments à côté.
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
Ca, c'est la version compliquée :-)
FiLH wrote:(Anonyme) writes:
> Laurent Pertois wrote:
>
>> mcx ?
>
> Ouais... Ok. Bien que je pense qu'on doit pouvoir mettre en place
> l'équivalent en dehors, mais j'avoue que ça ne m'intéresse pas trop de
Ben... quand t'as un ldap d'entreprise ailleurs... t'es bien obligé de
les y mettre les mcx.
Oui et non.
On peut étendre le schéma pour intégrer les attributs Apple qui
contiennent les mcx. Mais le plus simple est encore de faire un triangle
magique.
Ceci dit cela marche très bien. Juste que c'est *$%^#* d'Apple n'ont
pas documenté la syntaxe et donc faut faire du reverse ingeneering...
Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
faut aussi bien mapper pour qu'il trouve les éléments à côté.
Après tu code ton xml en base64 et hop t'injecte dans le ldap.
Ca, c'est la version compliquée :-)
> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
FiLH wrote:> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
Pour ce que tu vas y stocker...
Prend le mode Workgroup, il est fait pour ça.
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
Comme tu l'entends mais ça va en faire un paquet à tester...
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
Et si tu faisais un OpenDirectory quand même, que tu gérais les MCX sur
les groupes (et pas les comptes individuels) et que ce groupe géré
contenait en fait un groupe de ton LDAP ? comme ça, dans ton script de
création, tu n'as qu'à ajouter ton compte dans le bon groupe de ton LDAP
et boum, ça force les MCX. De plus, si tu dois modifier ces MCX tu n'es
du coup pas obligé de tout refaire sur chacun des comptes.
Enfin, moi je dis ça, je ne dis rien...
FiLH <filh@filh.org> wrote:
> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
Pour ce que tu vas y stocker...
Prend le mode Workgroup, il est fait pour ça.
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
Comme tu l'entends mais ça va en faire un paquet à tester...
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
Et si tu faisais un OpenDirectory quand même, que tu gérais les MCX sur
les groupes (et pas les comptes individuels) et que ce groupe géré
contenait en fait un groupe de ton LDAP ? comme ça, dans ton script de
création, tu n'as qu'à ajouter ton compte dans le bon groupe de ton LDAP
et boum, ça force les MCX. De plus, si tu dois modifier ces MCX tu n'es
du coup pas obligé de tout refaire sur chacun des comptes.
Enfin, moi je dis ça, je ne dis rien...
FiLH wrote:> On peut étendre le schéma pour intégrer les attributs Apple qui
> contiennent les mcx. Mais le plus simple est encore de faire un triangle
> magique.
Non : ça fait un serveur ldap de plus à entretenir. Aucun intérêt :)
Pour ce que tu vas y stocker...
Prend le mode Workgroup, il est fait pour ça.
> Pas besoin, tu prends le Workgroup Manager si tu as étendu ton schéma,
> il saura comment écrire ce qu'il faut sans tout casser autour. Bon, il
> faut aussi bien mapper pour qu'il trouve les éléments à côté.
Oui, c'est ce que j'appelle revers ingeenerinf : je fais un exemple
avec le workgroup, je récupère les valeurs et je les injecte moi même.
Comme tu l'entends mais ça va en faire un paquet à tester...
> Ca, c'est la version compliquée :-)
Non : car notre script d'ajout d'utilisateur est générique et fait
BEAUCOUP de choses (ben oui on est aussi Supann, et aussi PDC Sambaa,
et aussi nos attributs locaux pour la gestion des droits et
aussi....), plus des synchro avec un vieux serveur NIS, plus
probablement des synchro avec une fédération d'annuaire qui va se
créer, plus des sychros avec les bases de gestion des SI...
Bref c'est la version simple car on l'intègre direct au script de
création d'utilisateur et ça ne génère pas de boulot à l'ajout.
Et si tu faisais un OpenDirectory quand même, que tu gérais les MCX sur
les groupes (et pas les comptes individuels) et que ce groupe géré
contenait en fait un groupe de ton LDAP ? comme ça, dans ton script de
création, tu n'as qu'à ajouter ton compte dans le bon groupe de ton LDAP
et boum, ça force les MCX. De plus, si tu dois modifier ces MCX tu n'es
du coup pas obligé de tout refaire sur chacun des comptes.
Enfin, moi je dis ça, je ne dis rien...
Merci pour le lien. Cela confirme qu'il est possible d'utiliser le
système Mac avec de la ligne de commande. C'est déjà très pratique. Mais
peut-on se passer de l'interface graphique et obtenir la même
productivité qu'un linuxien accompli ?
c'est très probablement le cas pour des tâches classiques, et en tout
cas les outils sont là.
Ensuite, pour les tâches en apparence anodines dans la GUI (créer un
serveur VPN = 2 cliques), je doute que tu puisses faire ça en une ou
même deux lignes de commandes. Tu auras vraisemblablement une pelleté de
fichiers à éditer.
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
Merci pour le lien. Cela confirme qu'il est possible d'utiliser le
système Mac avec de la ligne de commande. C'est déjà très pratique. Mais
peut-on se passer de l'interface graphique et obtenir la même
productivité qu'un linuxien accompli ?
c'est très probablement le cas pour des tâches classiques, et en tout
cas les outils sont là.
Ensuite, pour les tâches en apparence anodines dans la GUI (créer un
serveur VPN = 2 cliques), je doute que tu puisses faire ça en une ou
même deux lignes de commandes. Tu auras vraisemblablement une pelleté de
fichiers à éditer.
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
Merci pour le lien. Cela confirme qu'il est possible d'utiliser le
système Mac avec de la ligne de commande. C'est déjà très pratique. Mais
peut-on se passer de l'interface graphique et obtenir la même
productivité qu'un linuxien accompli ?
c'est très probablement le cas pour des tâches classiques, et en tout
cas les outils sont là.
Ensuite, pour les tâches en apparence anodines dans la GUI (créer un
serveur VPN = 2 cliques), je doute que tu puisses faire ça en une ou
même deux lignes de commandes. Tu auras vraisemblablement une pelleté de
fichiers à éditer.
Moralité, tu auras peut être la même productivité qu'un linuxien
accompli, mais moins qu'un admin Mac OS X accompli (et paf le troll).
Anti CLI OS X serveur convaincu, puis-je ajouter qu'avec l'interface
graphique, c'est Apple qui bosse pour moi. Avec les commandes en ligne,
les modifs aux prefs ... on ne sait jamais bien où on va, y compris
lorsqu'un guru vous recommande une ligne de commande qui ne fait pas ce
qu'on attend ;-)
Heu... ben si on sait très bien où on va : il suffit de lire la doc,
car bon cliquer au hasard jusqu'à ce que ça marche (si j'ai bien compris
les principes de l'administration clicodromesque)... ça va cinq minutes.
Ou alors c'est qu'on a habitué les utilisateurs à ce que ça mette un
« certain temps » avant de marcher..
J'ai quelque doute sur un admi qui clique sans savoir le concept
dessous.
Et quand tu connais le concept, ben cli ou gui tu prendras l'outil le
plus adapté, c'est pas la différence entre une coche ou un argument qui
gènera.
Anti CLI OS X serveur convaincu, puis-je ajouter qu'avec l'interface
graphique, c'est Apple qui bosse pour moi. Avec les commandes en ligne,
les modifs aux prefs ... on ne sait jamais bien où on va, y compris
lorsqu'un guru vous recommande une ligne de commande qui ne fait pas ce
qu'on attend ;-)
Heu... ben si on sait très bien où on va : il suffit de lire la doc,
car bon cliquer au hasard jusqu'à ce que ça marche (si j'ai bien compris
les principes de l'administration clicodromesque)... ça va cinq minutes.
Ou alors c'est qu'on a habitué les utilisateurs à ce que ça mette un
« certain temps » avant de marcher..
J'ai quelque doute sur un admi qui clique sans savoir le concept
dessous.
Et quand tu connais le concept, ben cli ou gui tu prendras l'outil le
plus adapté, c'est pas la différence entre une coche ou un argument qui
gènera.
Anti CLI OS X serveur convaincu, puis-je ajouter qu'avec l'interface
graphique, c'est Apple qui bosse pour moi. Avec les commandes en ligne,
les modifs aux prefs ... on ne sait jamais bien où on va, y compris
lorsqu'un guru vous recommande une ligne de commande qui ne fait pas ce
qu'on attend ;-)
Heu... ben si on sait très bien où on va : il suffit de lire la doc,
car bon cliquer au hasard jusqu'à ce que ça marche (si j'ai bien compris
les principes de l'administration clicodromesque)... ça va cinq minutes.
Ou alors c'est qu'on a habitué les utilisateurs à ce que ça mette un
« certain temps » avant de marcher..
J'ai quelque doute sur un admi qui clique sans savoir le concept
dessous.
Et quand tu connais le concept, ben cli ou gui tu prendras l'outil le
plus adapté, c'est pas la différence entre une coche ou un argument qui
gènera.