reseau mac pc

Le
RJ
Bonjour,
Je travaille sous un réseau avec 2 mac et 5 pc (Xp)
je viens de passer pour les mac sous jaguar
et plus de réseau
mes adresses IP n'ont pas bougé
l'adresse du routeur non plus
même passrelle
même groupe de travail partage de fichiers activé
mais je ne vois plus personne et plus personne ne me voit
???
Merci d'avance
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Roaringriri
Le #3065611
Bonjour,
Je travaille sous un réseau avec 2 mac et 5 pc (Xp)
je viens de passer pour les mac sous jaguar
et plus de réseau
mes adresses IP n'ont pas bougé
l'adresse du routeur non plus
même passrelle
même groupe de travail partage de fichiers activé
mais je ne vois plus personne et plus personne ne me voit
???
Merci d'avance


Tu devrais arriver à le rétablir, mais ça va rester aléatoire, nous on à

un seul Mac en Léopard, sur 8 + 3 PC , et on perd le réseau un jour sur
3 ou 4. Ca nous oblige à resseter les switchs périodiquement.
Il y a plus génant, les dossiers publiés sur lees macs sont le plus
souvent inaccessibles (du poste en léopard), on a beau refaire les
autorisations tous les jours, le lendemain, c'est de nouveau perdu.
Il nous flingue aussi régulièrement l'init appletalk d'une carte LI2 LI5
qui est sur un autre poste pilotant un RIP.
On a aussi été obligé de réécrire des routines d'impression 4D en
réintroduisant des instructions obsoletes depuis 10 ans, pour pouvoir se
servir de nos imprimantes.
Globalement, cette mise à jour est une catastrophe.

Nicolas-MICHEL'_remove_'
Le #3064841
Roaringriri
Tu devrais arriver à le rétablir, mais ça va rester aléatoire, nous on à
un seul Mac en Léopard, sur 8 + 3 PC , et on perd le réseau un jour sur
3 ou 4.


sous quel protocole ? smb ?
Sauf erreur léopard a une nouvelle façon de configurer smb qui ne passe
pas uniquement par le smb.conf.
As-tu tenté de configurer ton smb.conf à la mano en supprimant les
excentricités Apple ?

Ca nous oblige à resseter les switchs périodiquement.
Il y a plus génant, les dossiers publiés sur lees macs sont le plus
souvent inaccessibles (du poste en léopard), on a beau refaire les
autorisations tous les jours, le lendemain, c'est de nouveau perdu.


Que veux tu dire par "refaire les autorisations" ?

Il nous flingue aussi régulièrement l'init appletalk d'une carte LI2 LI5
qui est sur un autre poste pilotant un RIP.
On a aussi été obligé de réécrire des routines d'impression 4D en
réintroduisant des instructions obsoletes depuis 10 ans, pour pouvoir se
servir de nos imprimantes.
Globalement, cette mise à jour est une catastrophe.


Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas

laurent.pertois
Le #3064611
Nicolas MICHEL
Sauf erreur léopard a une nouvelle façon de configurer smb qui ne passe
pas uniquement par le smb.conf.


Tiens, la parano recommence...

As-tu tenté de configurer ton smb.conf à la mano en supprimant les
excentricités Apple ?


Tss, tss, avant de dire des choses, il suffit de jeter un oeil, non ?

Déjà, dans le smb.conf, il y a des commentaires, ensuite, il y a un
include pointant sur un fichier qui est lui mis à jour par les outils
internes de l'OS :

; Pull in system-wide preference settings. These are managed by
; synchronize-preferences tool.
include = /var/db/smb.conf

Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.

De plus, si je lis ce man, il est bien précisé que le fichier smb.conf
doit être édité au traver de SWAT, ça sous-entendrait qu'il ne faut pas
l'éditer manuellement ?

Ces éléments sont dans une section de la conf qui est dès le départ
déclarée comme étant susceptibles d'être mise à jour et que les réglages
spécifiques doivent être faits en-dehors. Or à la fin, on trouve cette
ligne :

; Site-specific parameters can be added below this comment.



Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.


Nicolas, là, je vais me fâcher tout rouge...

Déjà c'est dans /var/db/dslocal/nodes/Default. Ensuite, explique-moi le
rapport avec la base de registres...

--
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'_remove_'
Le #3063471
Laurent Pertois
Nicolas MICHEL
Sauf erreur léopard a une nouvelle façon de configurer smb qui ne passe
pas uniquement par le smb.conf.


Tiens, la parano recommence...


parano ... on peut dire ça.

C'est que je crains que comme d'hab, ils aient fait un truc à leur
sauce, pas administrable en cli et bridé en GUI, avec des bugs.

Donc voyons ce que ça a de fondé ...

Bin déjà on en parle ici donc ça marche pas toujours comme ça devrait.
Roaringriri a l'air très content des nouvelles foutures.

As-tu tenté de configurer ton smb.conf à la mano en supprimant les
excentricités Apple ?


Tss, tss, avant de dire des choses, il suffit de jeter un oeil, non ?


Non, dans ce cas là un oeil, c'est à dire 10 ou 15 minutes, ne suffisent
pas. Mais je reviendrai sur ce point.

include = /var/db/smb.conf

Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.


Ok pour le include.
Mais il n'y a pas 2 mais 3 fichiers de conf. Tu oublies celui-ci :

/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist

Déjà rien que le nom m'énerve.
Et ça n'est pas un include documenté, c'est un truc à la sauce Apple.

Ensuite voyons ce qu'il y a à l'intérieur :

# defaults read
/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist
2008-02-25 09:27:48.999 defaults[329:10b]
Domain SystemConfiguration/com.apple.smb.server.plist does not exist

Tien donc. Apple n'a toujours pas corrigé ce bug. Etonnant, non ? ;->

Donc on retape la commande, sans l'extention cette fois ci :
# defaults read
/Library/Preferences/SystemConfiguration/com.apple.smb.server
{
DOSCodePage = 437;
KerberosRealm = "ICI.EPFL.CH";
LocalKerberosRealm = "LKDC:SHA1.6452D3[snip]";
NetBIOSName = "TU-42-006";
NetBIOSNodeType = Hybrid;
PasswordServer = "monserveur.epfl.ch";
ServerDescription = "SV-42-006";
ServerRole = ActiveDirectoryMember;
WINSServerAddressList = (
"123.145.156.144"
);
Workgroup = TU;
}

Rien de terrible, mais des redondances :
Il y a également un workgroup dans le fichier /var/db/smb.conf
Et aussi un realm nomé KerberosRealm.
etc ...

Donc on a 3 fichiers partiellement redondants. Dans quel ordre ils sont
générés et qu'est ce qui va foirer à la prochaine update, mystère.
Je ne donne pas cher de ma config manuelle dans cette histoire.

Ensuite regardons ce que testparm raconte ...
ouille, 42 lignes dans la section [global].

J'ai ici un vieux serveur linux, il est en prod depuis des années et son
testparm retourne une section [global] de 6 lignes.
Donc "avant" il suffisait de maitriser 6 paramètres, à présent on a
multiplié la complexité par 7 et le risque d'erreur avec.

Petit extrait du testparm :
(j'ai mis cette machine dans un domaine AD, soit dit en passant)

# testparm
[snip]
[global]
security = ADS
auth methods = guest, odsam
obey pam restrictions = Yes
passdb backend = odsam
lanman auth = No
use kerberos keytab = Yes
name resolve order = lmhosts wins bcast host
idmap domains = default
idmap alloc backend = odsam
com.apple:lkdc realm = LKDC:SHA1.6452[snip]
com.apple:filter shares by access = yes
darwin_streams:brlm = yes

Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.
Ce qu'il faut admettre, c'est que certains de ces points sont des ajouts
de samba, pas de Apple. (par ex. "idmap domains")
Par contre on a du darwin_streams et du com.apple:lkdc non documenté,
made in Apple

Or à la fin, on trouve cette ligne :
; Site-specific parameters can be added below this comment.


Oui, un point positif : il y a quelques commentaires.
Une lueur d'espoir en somme.

Bref, tout ça pour dire que non, c'est pas juste un oeil qu'il faut pour
apréhender les nouveautés que Lépopard apporte côté samba.
Il y a du taff, des surprises et des bugs en perspective.

Ils ont kerberisé samba et c'est une bonne chose.

Mais d'une façon globale on a indéniablement une augmentation de la
complexité du bouzin. Ton "coup d'oeil" ne permet que d'entrevoir le
problème. Pour le maitriser, c'est une autre paire de manche.

Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.


Nicolas, là, je vais me fâcher tout rouge...

Déjà c'est dans /var/db/dslocal/nodes/Default. Ensuite, explique-moi le
rapport avec la base de registres...


Le rapport, c'est que c'est pas fait pour être administré.
C'est une boite noir, Apple met ce qu'il veux dedant sans rendre de
compte à personne et se fout de savoir qu'il y a des admin derière qui
devront utiliser la chose.

Tiens, un petit test "amusant" :
Sur Tiger,
$ dscl localhost -read /Active
Directory/sv.intranet.epfl.ch/Users/namichel |wc -l
216

Sur Léopard, même commande, 248 lignes.

Contre une seule ligne dans le traditionnel /etc/passwd.

On est sensé administrer ce système, et pour ce faire les éléments sont
sensés être simples, accessible et documentés.
Mais plus ça va de l'avant, moins c'est le cas.

En fait je m'énerve à chaque nouvelle version de Mac OS X.
Déjà pour launchd, j'avais moussé et j'étais pas le seul.
Donc c'est "normal" je suppose, mais quand-même, de mémoire launchd
était buggé durant 2 ou 3 versions. (les "periodique" se lançaient pas)
Pourquoi ça serait différent avec léo ?

Et encore une fois, je me répète, c'est pas comme sous Windows où tout
le monde se fout de Vista, n'y prêtant attention qu'après la sp1.
Sur mac on subis chaque update, chaque bug, chaque fouture, parce qu'on
ne peut pas installer un vieux système sur un nouveau mac.

On ne nait pas parano, on le devient par expérience.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas


laurent.pertois
Le #3063391
Nicolas MICHEL
Laurent Pertois
Nicolas MICHEL
Sauf erreur léopard a une nouvelle façon de configurer smb qui ne passe
pas uniquement par le smb.conf.


Tiens, la parano recommence...


parano ... on peut dire ça.


;-)

C'est que je crains que comme d'hab, ils aient fait un truc à leur
sauce, pas administrable en cli et bridé en GUI, avec des bugs.


Valà, bien ce que je dis, parano... En même temps, Apple ne vend pas Mac
OS X comme un serveur donc il ne faut pas non plus leur en vouloir de
faire des choses qui les arrange, tant que ce que la GUI fait ce pour
quoi elle est vendue. Quand on cherche à détourner un outil de sa
destination finale et que ça se passe mal, il ne faut pas s'étonner.
J'arrive à dévisser avec un pince mais parfois la vis est cassée, je ne
râle pas contre le fabricant de la vis ;-)

Donc voyons ce que ça a de fondé ...

Bin déjà on en parle ici donc ça marche pas toujours comme ça devrait.


Allons bon...

Roaringriri a l'air très content des nouvelles foutures.

As-tu tenté de configurer ton smb.conf à la mano en supprimant les
excentricités Apple ?


Tss, tss, avant de dire des choses, il suffit de jeter un oeil, non ?


Non, dans ce cas là un oeil, c'est à dire 10 ou 15 minutes, ne suffisent
pas. Mais je reviendrai sur ce point.


Ai-je dit qu'il fallait se contenter de quelques secondes ?

include = /var/db/smb.conf

Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.


Ok pour le include.
Mais il n'y a pas 2 mais 3 fichiers de conf. Tu oublies celui-ci :

/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist


Non, je ne l'oublie pas, je vais y revenir...

Déjà rien que le nom m'énerve.
Et ça n'est pas un include documenté, c'est un truc à la sauce Apple.

Ensuite voyons ce qu'il y a à l'intérieur :

# defaults read
/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist
2008-02-25 09:27:48.999 defaults[329:10b]
Domain SystemConfiguration/com.apple.smb.server.plist does not exist

Tien donc. Apple n'a toujours pas corrigé ce bug. Etonnant, non ? ;->


It's not a bug, it's a feature, allons. Regarde PlistBuddy(8)...

Et puis, mentionner ça comme ça, c'est un peu de la mauvaise foi, mais
j'accepte ;-)

Donc on retape la commande, sans l'extention cette fois ci :
# defaults read
/Library/Preferences/SystemConfiguration/com.apple.smb.server
{
DOSCodePage = 437;
KerberosRealm = "ICI.EPFL.CH";
LocalKerberosRealm = "LKDC:SHA1.6452D3[snip]";
NetBIOSName = "TU-42-006";
NetBIOSNodeType = Hybrid;
PasswordServer = "monserveur.epfl.ch";
ServerDescription = "SV-42-006";
ServerRole = ActiveDirectoryMember;
WINSServerAddressList = (
"123.145.156.144"
);
Workgroup = TU;
}

Rien de terrible, mais des redondances :
Il y a également un workgroup dans le fichier /var/db/smb.conf
Et aussi un realm nomé KerberosRealm.
etc ...

Donc on a 3 fichiers partiellement redondants. Dans quel ordre ils sont
générés et qu'est ce qui va foirer à la prochaine update, mystère.
Je ne donne pas cher de ma config manuelle dans cette histoire.


Non, on n'a pas 3 fichiers mais 2, le plist dont tu parles est un
fichier intermédiaire qui est modifié quand tu touches à Préférences
Système, Partage. Ensuite, les infos inscrites dans ce fichiers plist
sont synchronisées par la commande
/usr/libexec/samba/synchronize-preferences qui est lancée par launchctl
dès que le fichier est modifié si j'en crois ce que j'observe. Le
fichier plist est lui sous la dépendance de configd.

Ensuite regardons ce que testparm raconte ...
ouille, 42 lignes dans la section [global].


Et ?

J'ai ici un vieux serveur linux, il est en prod depuis des années et son
testparm retourne une section [global] de 6 lignes.
Donc "avant" il suffisait de maitriser 6 paramètres, à présent on a
multiplié la complexité par 7 et le risque d'erreur avec.


Tss, tss... Mauvaise foi encore... tu me compares une machine configurée
pour être un serveur à une machine cliente proposant quelques fonctions
de partage et en plus permettant bien plus de choses que ce que tu as
fait peut-être avec ton linux...

Petit extrait du testparm :
(j'ai mis cette machine dans un domaine AD, soit dit en passant)


Et ton linux aussi ? et ton Linux est kerbérisé ?

# testparm
[snip]
[global]
security = ADS
auth methods = guest, odsam
obey pam restrictions = Yes
passdb backend = odsam
lanman auth = No
use kerberos keytab = Yes
name resolve order = lmhosts wins bcast host
idmap domains = default
idmap alloc backend = odsam
com.apple:lkdc realm = LKDC:SHA1.6452[snip]
com.apple:filter shares by access = yes
darwin_streams:brlm = yes

Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.


Et pourquoi pas ?

Ce qu'il faut admettre, c'est que certains de ces points sont des ajouts
de samba, pas de Apple. (par ex. "idmap domains")
Par contre on a du darwin_streams et du com.apple:lkdc non documenté,
made in Apple


Normal, tu connais d'autres OS qui ont un KDC local pour chaque poste
comme le fait Mac OS X v10.5 ? il fallait attendre que tout le monde s'y
mette pour que l'option arrive un jour ? et puis, tu te plains tout le
temps, mais cette fois c'est clair, ça commence par "com.apple:".


Là il devrait y avoir quelques infos :-)

Or à la fin, on trouve cette ligne :
; Site-specific parameters can be added below this comment.


Oui, un point positif : il y a quelques commentaires.
Une lueur d'espoir en somme.


Pas que d'espoir. Tu écris en-dessous tes configs et elles sont plus
fortes que celles du dessus vu qu'elles arrivent après. Et en plus, si
j'en crois ce que je vois, elles ne sont même pas écrasées...

Bref, tout ça pour dire que non, c'est pas juste un oeil qu'il faut pour
apréhender les nouveautés que Lépopard apporte côté samba.
Il y a du taff, des surprises et des bugs en perspective.


Il y a du taff quand on veut absolument qu'il y en ait en rejetant la
nouveauté, voyons. Ils essaient d'améliorer, ils laissent un espace de
liberté en arrivant à gérer leur propre espace automatisé et en plus, ça
râle. Que fait un swat sur des options qui ne sont pas prévues et que tu
as entré à la main ?

Ils ont kerberisé samba et c'est une bonne chose.


Ah :-) (ça m'a fait plaisir aussi, je t'avoue)

Mais d'une façon globale on a indéniablement une augmentation de la
complexité du bouzin. Ton "coup d'oeil" ne permet que d'entrevoir le
problème. Pour le maitriser, c'est une autre paire de manche.


Ce n'est pas pire que se taper toute la doc de Samba pour affiner sa
conf.

Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.


Nicolas, là, je vais me fâcher tout rouge...

Déjà c'est dans /var/db/dslocal/nodes/Default. Ensuite, explique-moi le
rapport avec la base de registres...


Le rapport, c'est que c'est pas fait pour être administré.


Ah ? allons bon...

C'est une boite noir, Apple met ce qu'il veux dedant sans rendre de
compte à personne et se fout de savoir qu'il y a des admin derière qui
devront utiliser la chose.


Hein ???

Quand on te donne une base de données binaire, tu râles, maintenant on
te donne du texte, certes en xml mais ne rêvons pas, Apple maîtrise bien
l'écriture de plists ils ne vont pas changer, tu râles encore...

Tiens, un petit test "amusant" :
Sur Tiger,
$ dscl localhost -read /Active
Directory/sv.intranet.epfl.ch/Users/namichel |wc -l
216

Sur Léopard, même commande, 248 lignes.

Contre une seule ligne dans le traditionnel /etc/passwd.


Et ?

Dans /etc/passwd je n'ai que des infos sur un compte local, là tu vas
chercher des infos sur un compte qui est dans un AD avec en plus des
mappages pour te permettre d'avoir quelque chose d'utilisable un minimum
sur un OS qui n'est pas pris en compte par la source.

De plus, c'est encore une fois de la mauvaise foi vu que les éléments de
/etc/passwd sont certes sur une seule ligne mais quand même multiples et
séparés par des ":" et si tu veux les zapper il faut laisser vide sans
se tromper sur le nombre de ":" à écrire sinon tu décales tout. Dans le
plist, si tu ne veux pas d'un attribut, ben, tu ne le mets pas, même pas
vide.

On est sensé administrer ce système, et pour ce faire les éléments sont
sensés être simples, accessible et documentés.
Mais plus ça va de l'avant, moins c'est le cas.


Mouhahahahahahahahahahahahaha... Arrête, je vais me faire repérer.

Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...

En fait je m'énerve à chaque nouvelle version de Mac OS X.


Oui, je trouve aussi. Maintenant, pour finir d'user tes nerfs, comparons
l'administration d'un BSD, d'un Solaris, d'un Debian et d'une RedHat et
voyons si exactement tout est au même endroit et se gère exactement de
la même manière.

Déjà pour launchd, j'avais moussé et j'étais pas le seul.


Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)

Donc c'est "normal" je suppose, mais quand-même, de mémoire launchd
était buggé durant 2 ou 3 versions. (les "periodique" se lançaient pas)
Pourquoi ça serait différent avec léo ?


Pourquoi ça serait différent ailleurs ?

Et encore une fois, je me répète, c'est pas comme sous Windows où tout
le monde se fout de Vista, n'y prêtant attention qu'après la sp1.
Sur mac on subis chaque update, chaque bug, chaque fouture, parce qu'on
ne peut pas installer un vieux système sur un nouveau mac.


Et je le répète, j'ai encore devant moi des admins qui doivent utiliser
Vista sur des portables n'ayant pas de drivers pour XP, des Sony.

On ne nait pas parano, on le devient par expérience.


On est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)

--
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'_remove_'
Le #3063281
Laurent Pertois
Valà, bien ce que je dis, parano... En même temps, Apple ne vend pas Mac
OS X comme un serveur donc il ne faut pas non plus leur en vouloir de
faire des choses qui les arrange, tant que ce que la GUI fait ce pour
quoi elle est vendue.


La GUI est sensé permettre de se connecter à un autre ordinateur.
Relis le post original ... Il y en a des 10aines des comme ça sur ce
même forum. Pas que sous Léopard, ça fait un bout de temps que c'est
n'importe quoi tout ça.

Mac OS 7 faisait mieux. En appletalk, certes, mais ça marchait.

It's not a bug, it's a feature, allons. Regarde PlistBuddy(8)...


En 2006, j'avais envoyé un bug report à ce sujet.
C'est tellement idiot ...

Quand à plistbuddy, euh, et si on parlait de ce qui est fournis par le
système de base ? ;->

Et puis, mentionner ça comme ça, c'est un peu de la mauvaise foi, mais
j'accepte ;-)


Sans vouloir remettre les defauts de defaults sur le tapis, disons que
ça montre bien, avec "man AppleFileServer" et consort, dans quelle
grande estime Apple place les admin Mac.
Mais je suis un brin de mauvaise foi, c'est entendu.

Non, on n'a pas 3 fichiers mais 2, le plist dont tu parles est un
fichier intermédiaire qui est modifié quand tu touches à Préférences
Système, Partage. Ensuite, les infos inscrites dans ce fichiers plist
sont synchronisées par la commande
/usr/libexec/samba/synchronize-preferences qui est lancée par launchctl
dès que le fichier est modifié si j'en crois ce que j'observe. Le
fichier plist est lui sous la dépendance de configd.


Ok, merci pour l'info.
Au fait, Directory Utility, ça ne m'étonnerais pas qu'il modifie aussi
le truc, vu qu'il y a des éléments kerberos automatiquement dans
smb.conf à présent. Je testerai la prochaine fois que j'aurai un mac
"propre".

Tss, tss... Mauvaise foi encore... tu me compares une machine configurée
pour être un serveur à une machine cliente proposant quelques fonctions
de partage et en plus permettant bien plus de choses que ce que tu as
fait peut-être avec ton linux...


Ce linux là fait ce qu'aucun de mes mac n'a jamais pu faire :
Un serveur AFP stable, en prod, sans jamais le moindre problème ;->
(enfin presque, le disque mort ne compte pas, il y avait du raid)

Ceci dit oui, il a une config simple. Et c'est bien à ça que sert linux
à mon niveau : monter un petit serveur dans un coin, qu'on oublie très
vite et qui marche très longtemps.

Et ton linux aussi ? et ton Linux est kerbérisé ?


kerberos au niveau du smb.conf c'est juste 2 lignes :

security = ADS
realm = ICI.CH

Ensuite tu fais ton "net join" et c'est réglé.
Bon, je passe un voile gracieux sur le bouzin kerberos préalable,
vu que c'est pas le sujet :)

Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.


Et pourquoi pas ?


Plus c'est compliqué, plus les risques de problèmes sont grands et moins
ils sont simples à résoudre.


Là il devrait y avoir quelques infos :-)


Merci, je regarderai ça demain.

Pas que d'espoir. Tu écris en-dessous tes configs et elles sont plus
fortes que celles du dessus vu qu'elles arrivent après. Et en plus, si
j'en crois ce que je vois, elles ne sont même pas écrasées...


Mouis, moques toi va :)

Il y a du taff quand on veut absolument qu'il y en ait en rejetant la
nouveauté, voyons. Ils essaient d'améliorer, ils laissent un espace de
liberté en arrivant à gérer leur propre espace automatisé et en plus, ça
râle. Que fait un swat sur des options qui ne sont pas prévues et que tu
as entré à la main ?


Je sais pas, je n'utilises pas ce genre de choses qui font des trucs que
je ne comprends pas. Je préfère faire à la main, le man dans la fenêtre
d'à côté, tranquille.

Ils ont kerberisé samba et c'est une bonne chose.


Ah :-) (ça m'a fait plaisir aussi, je t'avoue)


Si ça fonctionne, alors je vais carrément passer certaines machines en
10.5. Mais faut pas rêver, le pire est le plus sûr.
Question de probabilités.

Au mois en 10.4 résoudre un problème est "définitif" à présent :
pas d'update sur les anciennes version, donc c'est stabilisable.

Mais d'une façon globale on a indéniablement une augmentation de la
complexité du bouzin. Ton "coup d'oeil" ne permet que d'entrevoir le
problème. Pour le maitriser, c'est une autre paire de manche.


Ce n'est pas pire que se taper toute la doc de Samba pour affiner sa
conf.


La doc de samba, tu sais combien de pages elle a.
Tu sans quand tu commences, tu sais quand tu finis.
Avec Apple, no way, le temps que tu règles le problème un autre a surgit
à sa place. C'est le principe de la naissance spontanée.
J'ai déjà perdu quelques semaines à tracker des bugs qui mutent la
semaine d'après que j'aies trouvé le problème, c'est juste pas la peine
de tenter le coup.

Quand on te donne une base de données binaire, tu râles, maintenant on
te donne du texte, certes en xml mais ne rêvons pas, Apple maîtrise bien
l'écriture de plists ils ne vont pas changer, tu râles encore...


En fait je ne parlais pas du contennant, on s'y fait, mais du contennu.
Ce qu'ils mettent dedant fait peur. Et ça va pas en s'arrangeant.

Dans /etc/passwd je n'ai que des infos sur un compte local, là tu vas
chercher des infos sur un compte qui est dans un AD [snip] De plus,
c'est encore une fois de la mauvaise foi vu que les éléments de
/etc/passwd sont certes sur une seule ligne mais quand même multiples


Regarde par exemple pour un local user le champ AuthenticationAuthority.
Du fait que Mac OS X n'utilises pas pam, tu disais que c'est bien plus
simple de centraliser ça, que de définir l'authentification au niveau de
chaque service, c'est compliqué.
Peut-être, mais en attendant mettre ça au niveau de chaque utilsateur,
dans une boite de 20'000 personne c'est mieux peut-être ?

Sur le fond je penses que tu as compris ce que je veux dire. :)

Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...


Euh, quel fichier ? le .plist ? Et en 10.4 ?
Bon, plus sérieusement, si tu veux un truc compatible tu peux faire ça :

*******************
#!/bin/bash

username=${1:-toto}
RealName=${2:-"Toto Dahu"}
passwd=${3:-none}
idU=${4:-999}
idG=${5:-999}

#Create a new entry in the local (/) domain under the category /users.
dscl / -create /Users/$username
dscl / -create /Users/$username UserShell /bin/bash
dscl / -create /Users/$username RealName $RealName
dscl / -create /Users/$username UniqueID $idU
dscl / -create /Users/$username PrimaryGroupID $idG
dscl / -create /Users/$username NFSHomeDirectory /Users/$username

# Create the coresponding group

dscl / -create /Groups/$username
dscl / -create /Groups/$username PrimaryGroupID $idG
dscl / -create /Groups/$username Password *

# changement
expect <<EOF
spawn passwd $username
expect "New password:"
send -- "${passwd}r"
expect "Retype new password:"
send -- "${passwd}r"
expect eof
EOF

#adding admin right
dscl / -append /Groups/admin GroupMembership $username
*******************

Je l'ai balancé sur une 50aine de mac, ça fonctionne.
A présent, te dire que c'est corect et que j'avais pas besoins de mettre
de AuthenticationAuthority, j'en sais rien.


Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)


Mouarf, j'avais pas encore regardé ça.
Bon, ça promet ... Note que Launchd a déjà quelques années, avec un peu
de chance il est sec derrière les oreilles.

Donc ils ont remplacés les StartupItems par du launchd.
Au moins c'est cohérent.

Pourquoi ça serait différent ailleurs ?


Ailleur, si tu veux pas tu n'intalles pas.

Et je le répète, j'ai encore devant moi des admins qui doivent utiliser
Vista sur des portables n'ayant pas de drivers pour XP, des Sony.


Sur PC tu as le choix du fabricant.
Donc ils ont mal choisis.
Un admin système compétant ne se ferais avoir qu'une seule fois.
Bon, on est d'accord, M$ fait pression pour faire passer Vista.
Mais rien n'empêche d'installer MS-DOS ou NT4 sur un pc récent.

On est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)


;-)

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas


laurent.pertois
Le #3063241
Nicolas MICHEL
Laurent Pertois
Valà, bien ce que je dis, parano... En même temps, Apple ne vend pas Mac
OS X comme un serveur donc il ne faut pas non plus leur en vouloir de
faire des choses qui les arrange, tant que ce que la GUI fait ce pour
quoi elle est vendue.


La GUI est sensé permettre de se connecter à un autre ordinateur.
Relis le post original ... Il y en a des 10aines des comme ça sur ce
même forum. Pas que sous Léopard, ça fait un bout de temps que c'est
n'importe quoi tout ça.


Ben, donc on se prend la tête sur smb.conf alors qu'il s'agit d'un
soucis de navigation réseau ? dans ce cas, on peut arrêter de suite, ça
n'a rien à voir.

Mac OS 7 faisait mieux. En appletalk, certes, mais ça marchait.


Voilà, il manque AppleTalk sur Windows pour résoudre le problème.

It's not a bug, it's a feature, allons. Regarde PlistBuddy(8)...


En 2006, j'avais envoyé un bug report à ce sujet.
C'est tellement idiot ...


Je te l'ai déjà accordé.

Quand à plistbuddy, euh, et si on parlait de ce qui est fournis par le
système de base ? ;->


Mauvais système, changer de système cher Nicolas :

$ locate PlistBuddy | grep -v Receipts | grep -v
Applications/usr/libexec/PlistBuddy
/usr/share/man/man8/PlistBuddy.8

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.2
BuildVersion: 9C31


Et puis, mentionner ça comme ça, c'est un peu de la mauvaise foi, mais
j'accepte ;-)


Sans vouloir remettre les defauts de defaults sur le tapis, disons que
ça montre bien, avec "man AppleFileServer" et consort, dans quelle
grande estime Apple place les admin Mac.
Mais je suis un brin de mauvaise foi, c'est entendu.


Ah ! :-)

Non, on n'a pas 3 fichiers mais 2, le plist dont tu parles est un
fichier intermédiaire qui est modifié quand tu touches à Préférences
Système, Partage. Ensuite, les infos inscrites dans ce fichiers plist
sont synchronisées par la commande
/usr/libexec/samba/synchronize-preferences qui est lancée par launchctl
dès que le fichier est modifié si j'en crois ce que j'observe. Le
fichier plist est lui sous la dépendance de configd.


Ok, merci pour l'info.


Et pour info, j'ai pu déduire le tout rien qu'avec fseventer,
application trèèèèès utile pour voir qui touche quoi quand on clique :


Au fait, Directory Utility, ça ne m'étonnerais pas qu'il modifie aussi
le truc, vu qu'il y a des éléments kerberos automatiquement dans
smb.conf à présent. Je testerai la prochaine fois que j'aurai un mac
"propre".


Non, le LKDC est automatiquement configuré à l'installation. Ensuite,
Directory Utility configure une connexion à ton AD. Là, le fichier
/Library/Preferences/edu.mit.kerberos est configuré aussi et
effectivement on doit mettre à jour le smb.conf vu que Samba ne connait
_que_ ça. Et pourtant, Kerberos n'est pas une spécificité Mac OS X. Mais
dis-moi, quand tu fais une liaison AD avec Kerberisation de services sur
un Linux, ne dois-tu pas configurer plusieurs choses ?

Tss, tss... Mauvaise foi encore... tu me compares une machine configurée
pour être un serveur à une machine cliente proposant quelques fonctions
de partage et en plus permettant bien plus de choses que ce que tu as
fait peut-être avec ton linux...


Ce linux là fait ce qu'aucun de mes mac n'a jamais pu faire :
Un serveur AFP stable, en prod, sans jamais le moindre problème ;->
(enfin presque, le disque mort ne compte pas, il y avait du raid)


Je te fais grâce du disque. Pour le reste, tant mieux pour toi. J'ai ici
un serveur AFP, et même d'autres en clientèle, qui tournent comme des
horloges :->

Ceci dit oui, il a une config simple. Et c'est bien à ça que sert linux
à mon niveau : monter un petit serveur dans un coin, qu'on oublie très
vite et qui marche très longtemps.


Voilà, il fait peu de choses, tes Mac OS X en font presque plus si on va
par là.

Et ton linux aussi ? et ton Linux est kerbérisé ?


kerberos au niveau du smb.conf c'est juste 2 lignes :

security = ADS
realm = ICI.CH

Ensuite tu fais ton "net join" et c'est réglé.
Bon, je passe un voile gracieux sur le bouzin kerberos préalable,
vu que c'est pas le sujet :)


Euh si, c'est le sujet, sans le bordel autour, est-ce que ça fonctionne
?

Et à la fin du net join, tes autres services (netatalk, ssh, etc) sont
kerbérisés ?

Et là, Mac OS X arrive, il te permet en quelques clics de faire pareil,
éventuellement complété si c'est un client d'un peu de commandes, et tu
trouves le moyen de me dire que c'est mieux ailleurs vu qu'on peut, une
fois qu'on en a sué sang et eau, faire un truc qui devrait fonctionner
mais on n'en parle pas vu que, non, ça n'a rien à voir.

Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.


Et pourquoi pas ?


Plus c'est compliqué, plus les risques de problèmes sont grands et moins
ils sont simples à résoudre.


Sauf que je te rappelle que Mac OS X gère différentes sources pour
l'authentification, si on ne les mappe pas, l'utilisateur ne va pas
comprendre pourquoi le compte truc ne fonctionne pas.

Pas que d'espoir. Tu écris en-dessous tes configs et elles sont plus
fortes que celles du dessus vu qu'elles arrivent après. Et en plus, si
j'en crois ce que je vois, elles ne sont même pas écrasées...


Mouis, moques toi va :)


Ben non, là, j'explique :-)

Il y a du taff quand on veut absolument qu'il y en ait en rejetant la
nouveauté, voyons. Ils essaient d'améliorer, ils laissent un espace de
liberté en arrivant à gérer leur propre espace automatisé et en plus, ça
râle. Que fait un swat sur des options qui ne sont pas prévues et que tu
as entré à la main ?


Je sais pas, je n'utilises pas ce genre de choses qui font des trucs que
je ne comprends pas. Je préfère faire à la main, le man dans la fenêtre
d'à côté, tranquille.


Pourtant, si je lis bien le man de smb.conf(5)

The smb.conf file is designed to be configured and administered by the
swat(8) program.

Flûte, moi qui pensais qu'il fallait tout faire à la main...

Ils ont kerberisé samba et c'est une bonne chose.


Ah :-) (ça m'a fait plaisir aussi, je t'avoue)


Si ça fonctionne, alors je vais carrément passer certaines machines en
10.5. Mais faut pas rêver, le pire est le plus sûr.
Question de probabilités.


Nicolas...

Au mois en 10.4 résoudre un problème est "définitif" à présent :
pas d'update sur les anciennes version, donc c'est stabilisable.


Sauf les updates de sécurité qui peuvent intégrer samba vu que ce
dernier peut avoir une faille. Je sais, tu vas me dire qu'Apple ne met
jamais à jour samba, il n'y a qu'à voir la version sauf qu'ils patchent
leur version avec les correctifs de sécurité, dommage.

Ce n'est pas pire que se taper toute la doc de Samba pour affiner sa
conf.


La doc de samba, tu sais combien de pages elle a.


Non et ?

Tu sans quand tu commences, tu sais quand tu finis.


Ah ? ils n'ajoutent donc jamais rien. Flûte, c'est figé ?

Avec Apple, no way, le temps que tu règles le problème un autre a surgit
à sa place. C'est le principe de la naissance spontanée.


Mais bien sûr, Samba ne pose jamais de soucis lui-même quand tu mets à
jour. Mises à jour qui, d'ailleurs, ne servent en fait à rien vu qu'ils
n'ajoutent rien et ne corrigent rien.

Et puis, bon, la 3 commence à avoir de la bouteille, on en reparle à la
sortie de la 4 ?

J'ai déjà perdu quelques semaines à tracker des bugs qui mutent la
semaine d'après que j'aies trouvé le problème, c'est juste pas la peine
de tenter le coup.


Dingue, ils ont muté sans mise à jour en plus ?

Des bugs, il y en a, oui, j'en ai même quelques-uns référencés. Mais tu
ne me feras jamais croire qu'il n'y en a pas ailleurs. Je ne vais pas
aller sur des forums Samba/Linux pour faire une liste quand même ?

Quand on te donne une base de données binaire, tu râles, maintenant on
te donne du texte, certes en xml mais ne rêvons pas, Apple maîtrise bien
l'écriture de plists ils ne vont pas changer, tu râles encore...


En fait je ne parlais pas du contennant, on s'y fait, mais du contennu.
Ce qu'ils mettent dedant fait peur. Et ça va pas en s'arrangeant.


Hein ???

Dans /etc/passwd je n'ai que des infos sur un compte local, là tu vas
chercher des infos sur un compte qui est dans un AD [snip] De plus,
c'est encore une fois de la mauvaise foi vu que les éléments de
/etc/passwd sont certes sur une seule ligne mais quand même multiples


Regarde par exemple pour un local user le champ AuthenticationAuthority.


C'est fou ce que c'est compliqué comme champs...

$ dscl . -read /Users/laurent AuthenticationAuthority
AuthenticationAuthority: ;ShadowHash;HASHLIST:<SALTED-SHA1>
;Kerberosv5;;:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;
LKDC:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;

Alors, reprenons dans l'ordre, j'ai un mot de passe de type Shadow, donc
sur Mac OS X rangé dans /var/db/shadow/hash, il intègre uniquement
(c'est plus sûr) une hash de type SSHA1 et en plus, depuis la 10.5 j'ai
aussi une entrée dans le LKDC.

Pfiouuuu, c'est hardcore, tu as raison.

Du fait que Mac OS X n'utilises pas pam, tu disais que c'est bien plus
simple de centraliser ça, que de définir l'authentification au niveau de
chaque service, c'est compliqué.
Peut-être, mais en attendant mettre ça au niveau de chaque utilsateur,
dans une boite de 20'000 personne c'est mieux peut-être ?


Je ne te suis pas du tout. Tu préfères quoi ? devoir créer des entrées
utilisateur dans chaque service pour chaque compte ?

Là, je te rappelle que l'on parle de Mac OS X qui n'a pas vocation à se
substituer à un serveur avec un Open Directory configuré en mode Maître
qui va lui utiliser Kerberos et un Serveur de Mot de Passe pour
centraliser et répliquer ces informations.

Sur le fond je penses que tu as compris ce que je veux dire. :)


Là, j'avoue que non, désolé (et je ne trolle pas une seule seconde)

Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...


Euh, quel fichier ? le .plist ? Et en 10.4 ?


Nicolas, tu me parles de 10.5 et quand ça t'arrange tu repasses en 10.4,
c'est un peu facile. Si tu le souhaites je cherche de vieilles docs sur
Samba 2 qui posait des soucis en ne gérant pas l'authentification
Kerberos et en ne s'intégrant dans un domaine AD qu'en mode NT4...

Bon, plus sérieusement, si tu veux un truc compatible tu peux faire ça :



(snip le vieux script)

Je l'ai balancé sur une 50aine de mac, ça fonctionne.


Bien.

Bon, il y a un truc pas propre au moins, on ajoute dans les groupes avec
dseditgroup(8).

A présent, te dire que c'est corect et que j'avais pas besoins de mettre
de AuthenticationAuthority, j'en sais rien.


Ben, elle donne quoi ?

Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)


Mouarf, j'avais pas encore regardé ça.
Bon, ça promet ... Note que Launchd a déjà quelques années, avec un peu
de chance il est sec derrière les oreilles.


Comme toutes les technos, elles évoluent toutes. Tu crois que Samba et
autres Linux étaient aussi évolués et secs à leur début ?

Donc ils ont remplacés les StartupItems par du launchd.
Au moins c'est cohérent.


Oui et ils l'ont fini.

Pourquoi ça serait différent ailleurs ?


Ailleur, si tu veux pas tu n'intalles pas.


Bonsanmésébiensur. Je peux ne pas installer certains éléments de base
sur les autres OS et ils fonctionnent...

Et je le répète, j'ai encore devant moi des admins qui doivent utiliser
Vista sur des portables n'ayant pas de drivers pour XP, des Sony.


Sur PC tu as le choix du fabricant.


Pas toujours en entreprise.

Donc ils ont mal choisis.


Ils ont pris ce qu'on leur a permis d'acheter d'une part et ce que
l'utilisateur très influent a voulu.

Un admin système compétant ne se ferais avoir qu'une seule fois.


Non, il n'a pas toujours le choix, il y a des cas où il doit se taire
quel que soit le choix fait.

Bon, on est d'accord, M$ fait pression pour faire passer Vista.


Naaaaannnnnnn ???

Mais rien n'empêche d'installer MS-DOS ou NT4 sur un pc récent.


Avec quel support ? ce n'est pas toi qui me parlait du manque de support
d'Apple ? et pourtant MS assure plus longtemps mais là, j'ai
l'impression qu'ils découvrent qu'assurer moins longtemps ça permet de
forcer quelques mains.

On est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)


;-)


:-D

--
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'_remove_'
Le #3028221
Laurent Pertois
Mauvais système, changer de système cher Nicolas :
ProductVersion: 10.5.2


Dans notre inventaire, il n'y a que 226 mac.
A combien estimes-tu le cout d'une update léopard généralisée ?
Et qu'y gagnerait-on ?

Et pour info, j'ai pu déduire le tout rien qu'avec fseventer,
application trèèèèès utile pour voir qui touche quoi quand on clique :



Merci, je ne connaissais pas. J'ai de la lecture, décidément.

Mais dis-moi, quand tu fais une liaison AD avec Kerberisation de services
sur un Linux, ne dois-tu pas configurer plusieurs choses ?


Habituellement j'utilise cette doc :
<http://doc.ubuntu-fr.org/tutoriel/comment_ajouter_machine_ubuntu_dans_d
omaine_active_directory>
C'est clair, on le fait pas à pas et s'il y a un problème on peut
l'isoler facilement parce qu'il y a un test à chaque étape.
A chaque étape on peut creuser au besoins avec les man pages ou autre

Comparativement, avec Apple, ça marche ou ça marche pas.
C'est plus simple, mais est-ce mieux ?

Et quand on te sort qu'il faut balancer un
killall -USR1 DirectoryService
Puis te fritter un log imbitable pour retrouver le problème, merci.
On passe d'un coup du meilleur au pire, sans passer par la case départ.

Je te fais grâce du disque. Pour le reste, tant mieux pour toi. J'ai ici
un serveur AFP, et même d'autres en clientèle, qui tournent comme des
horloges :->


Ce sont des "Mac OS X server" ou juste du client ?

Voilà, il fait peu de choses, tes Mac OS X en font presque plus si on va
par là.


Ce qui m'intéresse, c'est que ça fasse ce dont j'ai besoins.
Et je choisis l'outil en fonction.

Et à la fin du net join, tes autres services (netatalk, ssh, etc) sont
kerbérisés ?


J'attends qu'on me le demande, mais ça ne me fait pas peur.

Et là, Mac OS X arrive, il te permet en quelques clics de faire pareil,
éventuellement complété si c'est un client d'un peu de commandes, et tu
trouves le moyen de me dire que c'est mieux ailleurs vu qu'on peut, une
fois qu'on en a sué sang et eau, faire un truc qui devrait fonctionner
mais on n'en parle pas vu que, non, ça n'a rien à voir.


Suer ne me dérange pas si le résulat est stable pour les 3 à 5 ans à
venir.

Plus c'est compliqué, plus les risques de problèmes sont grands et moins
ils sont simples à résoudre.


Sauf que je te rappelle que Mac OS X gère différentes sources pour
l'authentification, si on ne les mappe pas, l'utilisateur ne va pas
comprendre pourquoi le compte truc ne fonctionne pas.


Quel système ne gère-t-il pas différentes sources d'authentification ?

Pourtant, si je lis bien le man de smb.conf(5)

The smb.conf file is designed to be configured and administered by the
swat(8) program.


Bon, ok pour swat. Merci.
Encore de la lecture ... :)

Ah ? ils n'ajoutent donc jamais rien. Flûte, c'est figé ?


On doit pouvoir installer samba 2 sur un linux récent, mais j'ai pas eu
à le faire.

Par contre avec le NFS, ça j'ai déjà eu à adapter un serveur linux à Mac
OS X, qui a eu pendant longtemps une vielle version, sans possibilité
"simple" d'update. (on a vu il me semble des problèmes similaires avec
samba ou apache, non ?)
Donc non, c'est pas Linux qui est figé, ce serait plutôt Mac OS X.
Et quand ça change, c'est pas parce que tu l'as décidé, c'est que Apple
l'a décidé et hop, c'est comme ça, il faut t'adapter, pas le choix.

Mais bien sûr, Samba ne pose jamais de soucis lui-même quand tu mets à
jour. Mises à jour qui, d'ailleurs, ne servent en fait à rien vu qu'ils
n'ajoutent rien et ne corrigent rien.


Jamais rien ne m'est arrivé de ce genre sur nos quelques machines linux.
Par contre, les dépendances foireuses, ... bon, chaque system a ses
aventages et ses inconveignants, c'est bien clair.

Des bugs, il y en a, oui, j'en ai même quelques-uns référencés. Mais tu
ne me feras jamais croire qu'il n'y en a pas ailleurs. Je ne vais pas
aller sur des forums Samba/Linux pour faire une liste quand même ?


Non, c'est bon, quand je veux critiquer linux je vais sur un forum
linux, c'est plus marrant. :)
(parce que j'aime bien aussi critiquer linux. Il n'y a guère que windows
que je ne critique pas. Il n'en vaut pas la peine.)

C'est fou ce que c'est compliqué comme champs...

$ dscl . -read /Users/laurent AuthenticationAuthority
AuthenticationAuthority: ;ShadowHash;HASHLIST:<SALTED-SHA1>
;Kerberosv5;;:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;
LKDC:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;

Alors, reprenons dans l'ordre, j'ai un mot de passe de type Shadow, donc
sur Mac OS X rangé dans /var/db/shadow/hash, il intègre uniquement
(c'est plus sûr) une hash de type SSHA1 et en plus, depuis la 10.5 j'ai
aussi une entrée dans le LKDC.

Pfiouuuu, c'est hardcore, tu as raison.


Bon, merci pour l'explication.
Ce qui m'inquiète, c'est ce que ça va amener comme problème ou solutions
Pour l'instant j'ai d'autres chats à fouetter mais d'ici quelques moi
j'espère avoir le temps de prendre ça en main pour ré-implémenter une
intégration LADP, AD + OD avec sso, délocalisation, mcx et tout le
toutim. On verra à ce moment là si c'est un plus ou une encouble.

Je ne te suis pas du tout. Tu préfères quoi ? devoir créer des entrées
utilisateur dans chaque service pour chaque compte ?


Si je prends notre serveur AD, je ne retrouve pas ce type d'info dans
les comptes utilisateurs. Comment font-ils ?
Bref, innutile de discuter des choix technique de Apple, C'est comme ça.

Là, je te rappelle que l'on parle de Mac OS X qui n'a pas vocation à se
substituer à un serveur avec un Open Directory configuré en mode Maître
qui va lui utiliser Kerberos et un Serveur de Mot de Passe pour
centraliser et répliquer ces informations.


C'est le point de vue de Apple. Sauf que les entreprises ou les uni que
je connais ont de l'AD ou du ldap, pas du OD, Et c'était en place avant
que l'OD ne débarque.

Apple, d'un côté, voudrait promouvoir le mac en milieu pro mais de
l'autre, j'ai la vague impression qu'ils font un forcing sur l'OD.

Bon, il y a un truc pas propre au moins, on ajoute dans les groupes avec
dseditgroup(8).


pas compatiblle 10.3
Mais merci, je ne connaissait pas.
Pff, encore de la lecture :)

Ben, elle donne quoi ?


Mon vieux script a passé comme une lettre à la poste.
Mais je ne crois pas qu'il y avait du léopard dans le lot.

Bonsanmésébiensur. Je peux ne pas installer certains éléments de base
sur les autres OS et ils fonctionnent...


Cela dépends de ce que tu appelles "de base" et ce que tu entends par
"ils fonctionnent". Tu as dit bien aimer gentoo, regarde ce que
comprends l'install de base :)

Pas toujours en entreprise.
Ils ont pris ce qu'on leur a permis d'acheter d'une part et ce que
l'utilisateur très influent a voulu.
Non, il n'a pas toujours le choix, il y a des cas où il doit se taire
quel que soit le choix fait.


ça n'est pas un problème d'informatique au sens strict,
c'est des problèmes internes à l'entreprise, de pouvoir et autre.

Ici on va bientôt supporter et installer Vista, mais jusqu'à présent à
part sur des machines de test on en avait pas.
Ce qui est normal, on installe pas un windows avant le sp1.

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas


Nicolas-MICHEL'_remove_'
Le #3026151
Laurent Pertois
Regarde par exemple pour un local user le champ AuthenticationAuthority.


C'est fou ce que c'est compliqué comme champs...

$ dscl . -read /Users/laurent AuthenticationAuthority
AuthenticationAuthority: ;ShadowHash;HASHLIST:<SALTED-SHA1>
;Kerberosv5;;:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;
LKDC:SHA1.0AB026894D59AD7EF76A329BB6264CEF12E72F14;

Alors, reprenons dans l'ordre, j'ai un mot de passe de type Shadow, donc
sur Mac OS X rangé dans /var/db/shadow/hash, il intègre uniquement
(c'est plus sûr) une hash de type SSHA1 et en plus, depuis la 10.5 j'ai
aussi une entrée dans le LKDC.

Pfiouuuu, c'est hardcore, tu as raison.


Je viens justement d'avoir un problème d'authentification.
Un MacBook sous Léopard qui est dans notre domaine AD

L'utilisatrice est venue me trouver, elle me disait ne plus pouvoir se
loguer. Au moment où elle a ouvert son MacBook le login s'est fait.

Après quelques tests, j'en conclus ceci :
login sur le réseau : 4 secondes.
Login sur un autre réseau : 6 minutes.
Sur une autre machine, le login sur un autre réseau ne dure "que" 3
minutes. Donc c'est plus ou moins reproductible.

J'ai pas vu d'erreur significatives dans les logs.

Si je lance dscl puis que je fais un "ls", ou si j'ouvre Directory
Utility, 2 minutes à attendre si je suis pas sur le bon réseau.

Donc voilà, c'est très bien cette histoire d'authentification
multisources, mais qu'est ce qu'on fait quand ça marche pas ?
Est-ce qu'on peut y changer quelque chose ?
Où trouver de la doc à ce sujet ?

J'ai tenté de mettre un timeout du kerberos à 10 secondes,
mais ça n'a rien changé.




Au passage, (mais ça je m'en fiche un peu) sur les 2 léopards que j'ai
pu voir les periodic n'ont jamais été fait.
Avez-vous aussi constaté ce problème ?

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas


sebastienmarty
Le #3026121
Nicolas MICHEL
Au passage, (mais ça je m'en fiche un peu) sur les 2 léopards que j'ai
pu voir les periodic n'ont jamais été fait.
Avez-vous aussi constaté ce problème ?


Non, ils se lancent parfaitement bien ici, que ce soit le quotidien,
l'hebdomadaire ou le mensuel (vérifié à l'instant dans la console).

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)

Publicité
Poster une réponse
Anonyme