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 à
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 à
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 à
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.
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.
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.
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 ?
Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.
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 ?
Faut dire que depuis que Apple a mis une base de registre dans son
système, (/var/sb/dslocal) j'en viens à aimer windows.
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 ?
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 <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote: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 ?
include = /var/db/smb.conf
Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.
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...
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
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 ?
include = /var/db/smb.conf
Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.
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...
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote: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 ?
include = /var/db/smb.conf
Le include faisant partie du man de smb.conf, je ne vois rien de
dramatique.
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...
Laurent Pertois wrote:Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote: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.
Laurent Pertois <laurent.pertois@alussinan.org> wrote:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
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.
Laurent Pertois wrote:Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote: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.
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.
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 ;-)
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.
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...
Et ton linux aussi ? et ton Linux est kerbérisé ?
Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.
Et pourquoi pas ?
<http://www.opensource.apple.com/darwinsource/10.5/samba-187/>
Là il devrait y avoir quelques infos :-)
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...
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.
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...
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
Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...
Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)
Pourquoi ça serait différent ailleurs ?
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 est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)
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.
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 ;-)
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.
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...
Et ton linux aussi ? et ton Linux est kerbérisé ?
Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.
Et pourquoi pas ?
<http://www.opensource.apple.com/darwinsource/10.5/samba-187/>
Là il devrait y avoir quelques infos :-)
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...
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.
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...
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
Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...
Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)
Pourquoi ça serait différent ailleurs ?
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 est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)
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.
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 ;-)
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.
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...
Et ton linux aussi ? et ton Linux est kerbérisé ?
Alors on a du kerberos, du pam, du passdb, du od, en toute simplicité.
Et pourquoi pas ?
<http://www.opensource.apple.com/darwinsource/10.5/samba-187/>
Là il devrait y avoir quelques infos :-)
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...
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.
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...
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
Avec /etc/passwd, je peux créer un compte en ajoutant une ligne, avec
DSLocal, je n'ai qu'à copier un fichier. Vachement compliqué...
Mais launchd a aussi évolué, regarde, il y a plein de fichiers dans
/System/Library/LaunchDaemons :-)
Pourquoi ça serait différent ailleurs ?
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 est tous paranos. Enfin pas moi, je ne suis pas parano, c'est juste
que tout le monde m'en veut ;-)
Laurent Pertois wrote: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.
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.
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 :
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 ;-)
;-)
Laurent Pertois <laurent.pertois@alussinan.org> wrote:
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.
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.
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 :
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 ;-)
;-)
Laurent Pertois wrote: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.
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.
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 :
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 ;-)
;-)
Mauvais système, changer de système cher Nicolas :
ProductVersion: 10.5.2
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 :
<http://www.fernlightning.com/doku.php?id=software:fseventer:start>
Mais dis-moi, quand tu fais une liaison AD avec Kerberisation de services
sur un Linux, ne dois-tu pas configurer plusieurs choses ?
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 :->
Voilà, il fait peu de choses, tes Mac OS X en font presque plus si on va
par là.
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.
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.
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.
Ah ? ils n'ajoutent donc jamais rien. Flûte, c'est figé ?
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.
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 ?
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 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.
Bon, il y a un truc pas propre au moins, on ajoute dans les groupes avec
dseditgroup(8).
Ben, elle donne quoi ?
Bonsanmésébiensur. Je peux ne pas installer certains éléments de base
sur les autres OS et ils fonctionnent...
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.
Mauvais système, changer de système cher Nicolas :
ProductVersion: 10.5.2
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 :
<http://www.fernlightning.com/doku.php?id=software:fseventer:start>
Mais dis-moi, quand tu fais une liaison AD avec Kerberisation de services
sur un Linux, ne dois-tu pas configurer plusieurs choses ?
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 :->
Voilà, il fait peu de choses, tes Mac OS X en font presque plus si on va
par là.
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.
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.
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.
Ah ? ils n'ajoutent donc jamais rien. Flûte, c'est figé ?
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.
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 ?
C'est fou ce que c'est compliqué comme champs...
$ dscl . -read /Users/laurent AuthenticationAuthority
AuthenticationAuthority: ;ShadowHash;HASHLIST:<SALTED-SHA1>
;Kerberosv5;;laurent@LKDC: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 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.
Bon, il y a un truc pas propre au moins, on ajoute dans les groupes avec
dseditgroup(8).
Ben, elle donne quoi ?
Bonsanmésébiensur. Je peux ne pas installer certains éléments de base
sur les autres OS et ils fonctionnent...
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.
Mauvais système, changer de système cher Nicolas :
ProductVersion: 10.5.2
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 :
<http://www.fernlightning.com/doku.php?id=software:fseventer:start>
Mais dis-moi, quand tu fais une liaison AD avec Kerberisation de services
sur un Linux, ne dois-tu pas configurer plusieurs choses ?
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 :->
Voilà, il fait peu de choses, tes Mac OS X en font presque plus si on va
par là.
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.
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.
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.
Ah ? ils n'ajoutent donc jamais rien. Flûte, c'est figé ?
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.
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 ?
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 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.
Bon, il y a un truc pas propre au moins, on ajoute dans les groupes avec
dseditgroup(8).
Ben, elle donne quoi ?
Bonsanmésébiensur. Je peux ne pas installer certains éléments de base
sur les autres OS et ils fonctionnent...
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.
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.
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;;laurent@LKDC: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.
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.
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 ?
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 ?
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 ?