Je souhaite me lancer dans la synchronisation quotidienne de 2
machines avec rsync (documents, Mail, Carnet d'adresses, iPhoto ...),
en passant par un disque dur externe (je ne suis pas int=E9reress=E9
par .mac).
Comment faire pour qu'il n'y ait pas de probl=E8me de droits lors des
copies ?
Les 2 machines ont le m=EAme nom de compte Home mais pas les m=EAmes
informations GID/UID.
J'ai cru comprendre qu'il fallait mieux uniformiser ces informations
(UID et GID) entre les 2 machines pour =EAtre tranquille, avec
l'application NetInfo. Qu'en est-il du champ generatediud ?
Faut-il changer les valeurs UID et GID en tant que root ?
Si. Tous les utilisateurs créés sur un Mac OS X 10.4 ou supérieur en ont obligatoirement un.
www et autres utilisateurs systèmes n'en ont effectivement pas, mais ils n'en ont pas besoin, en fait.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Matt <ebbgjrvyre93@gmail.com.invalid> wrote:
Si. Tous les utilisateurs créés sur un Mac OS X 10.4 ou supérieur en ont
obligatoirement un.
www et autres utilisateurs systèmes n'en ont effectivement pas, mais ils
n'en ont pas besoin, en fait.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Si. Tous les utilisateurs créés sur un Mac OS X 10.4 ou supérieur en ont obligatoirement un.
www et autres utilisateurs systèmes n'en ont effectivement pas, mais ils n'en ont pas besoin, en fait.
-- 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
Laurent Pertois wrote:
Nicolas MICHEL wrote:
A présent pour le generateduid de Mac OS X, à vrais dire je ne le pratiques pas et je en sais pas exactement à quoi il sert.
Si, tu le pratiques sans le savoir :)
Ce que je voulais dire, c'est que j'ai jamais eu à m'en occuper.
En fait, c'est utilisé partout où tu as besoin d'être certain que l'utilisateur est bien uniquement celui que tu vises. Par exemple, les ACLs utilisent l'uuid et pas l'uid qui, dans le cas d'un serveur qui regrouperait des bases différentes, pourrait ne pas être unique.
Cette histoire d'acl me fait bien rire : chmod: Unable to translate 2FDB0001-1F52-11B9-AB85-000A95C12F6A to a UID/GID: Invalid argument
Sur ce coup le generateduid aurait pu nous servire à quelque chose : ça aurait pu résoudre ce foutu bug dans chmod qui fait qu'on ne peux pas assigner une acl à un groupe lorsqu'il existe un utilisateur du même nom
Au fait, t'as trouvé où cette info sur les ACL ?
De même, si tu joues avec les groupes tu remarqueras qu'ils ont aussi un UUID, ce dernier étant utilisé à nouveau pour les groupes imbriqués, les groupes dans les groupes (commande dseditgroup).
Ok. Je viens de tester en local avec le Workgroup manager, en effêt ça ajoutes un attribut "nestedgroups" avec les generateduid dedant. Bon, d'accord, ce binz ne nous est pas totalement innutile.
M'enfin ça me semble quand même passablement débile : Comment peut-on décider de parer aux incohérences réseau avec un truc innutilisable par 95% des ordinateurs ?
Le dn, il n'est pas assez unique ? Ou alors il sent mauvais ?
A présent pour le generateduid de Mac OS X, à vrais dire je ne le
pratiques pas et je en sais pas exactement à quoi il sert.
Si, tu le pratiques sans le savoir :)
Ce que je voulais dire, c'est que j'ai jamais eu à m'en occuper.
En fait, c'est utilisé partout où tu as besoin d'être certain que
l'utilisateur est bien uniquement celui que tu vises. Par exemple, les
ACLs utilisent l'uuid et pas l'uid qui, dans le cas d'un serveur qui
regrouperait des bases différentes, pourrait ne pas être unique.
Cette histoire d'acl me fait bien rire :
chmod: Unable to translate 2FDB0001-1F52-11B9-AB85-000A95C12F6A to a
UID/GID: Invalid argument
Sur ce coup le generateduid aurait pu nous servire à quelque chose :
ça aurait pu résoudre ce foutu bug dans chmod qui fait qu'on ne peux pas
assigner une acl à un groupe lorsqu'il existe un utilisateur du même nom
Au fait, t'as trouvé où cette info sur les ACL ?
De
même, si tu joues avec les groupes tu remarqueras qu'ils ont aussi un
UUID, ce dernier étant utilisé à nouveau pour les groupes imbriqués, les
groupes dans les groupes (commande dseditgroup).
Ok. Je viens de tester en local avec le Workgroup manager, en effêt ça
ajoutes un attribut "nestedgroups" avec les generateduid dedant.
Bon, d'accord, ce binz ne nous est pas totalement innutile.
M'enfin ça me semble quand même passablement débile :
Comment peut-on décider de parer aux incohérences réseau avec un truc
innutilisable par 95% des ordinateurs ?
Le dn, il n'est pas assez unique ?
Ou alors il sent mauvais ?
A présent pour le generateduid de Mac OS X, à vrais dire je ne le pratiques pas et je en sais pas exactement à quoi il sert.
Si, tu le pratiques sans le savoir :)
Ce que je voulais dire, c'est que j'ai jamais eu à m'en occuper.
En fait, c'est utilisé partout où tu as besoin d'être certain que l'utilisateur est bien uniquement celui que tu vises. Par exemple, les ACLs utilisent l'uuid et pas l'uid qui, dans le cas d'un serveur qui regrouperait des bases différentes, pourrait ne pas être unique.
Cette histoire d'acl me fait bien rire : chmod: Unable to translate 2FDB0001-1F52-11B9-AB85-000A95C12F6A to a UID/GID: Invalid argument
Sur ce coup le generateduid aurait pu nous servire à quelque chose : ça aurait pu résoudre ce foutu bug dans chmod qui fait qu'on ne peux pas assigner une acl à un groupe lorsqu'il existe un utilisateur du même nom
Au fait, t'as trouvé où cette info sur les ACL ?
De même, si tu joues avec les groupes tu remarqueras qu'ils ont aussi un UUID, ce dernier étant utilisé à nouveau pour les groupes imbriqués, les groupes dans les groupes (commande dseditgroup).
Ok. Je viens de tester en local avec le Workgroup manager, en effêt ça ajoutes un attribut "nestedgroups" avec les generateduid dedant. Bon, d'accord, ce binz ne nous est pas totalement innutile.
M'enfin ça me semble quand même passablement débile : Comment peut-on décider de parer aux incohérences réseau avec un truc innutilisable par 95% des ordinateurs ?
Le dn, il n'est pas assez unique ? Ou alors il sent mauvais ?
-- Nicolas
Nina Popravka
On Thu, 1 Mar 2007 10:54:35 +0100, (Laurent Pertois) wrote:
Je ne me plains pas qu'il n'y en ait pas... C'est clair que ça facilite la vie quand on clone :)
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID. En revanche, j'ai déjà vu des situations catastrophiques sur des serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif pour récupérer le contenu d'Exchange :-(((( -- Nina
On Thu, 1 Mar 2007 10:54:35 +0100, laurent.pertois@alussinan.org
(Laurent Pertois) wrote:
Je ne me plains pas qu'il n'y en ait pas...
C'est clair que ça facilite la vie quand on clone :)
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID.
En revanche, j'ai déjà vu des situations catastrophiques sur des
serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif
pour récupérer le contenu d'Exchange :-((((
--
Nina
On Thu, 1 Mar 2007 10:54:35 +0100, (Laurent Pertois) wrote:
Je ne me plains pas qu'il n'y en ait pas... C'est clair que ça facilite la vie quand on clone :)
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID. En revanche, j'ai déjà vu des situations catastrophiques sur des serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif pour récupérer le contenu d'Exchange :-(((( -- Nina
laurent.pertois
Nina Popravka wrote:
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID.
C'est vrai.
En revanche, j'ai déjà vu des situations catastrophiques sur des serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif pour récupérer le contenu d'Exchange :-((((
Arf, pas glop ça, effectivement. Mais, bon, SBS, je n'ai jamais eu de bonnes relations avec lui...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam> wrote:
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID.
C'est vrai.
En revanche, j'ai déjà vu des situations catastrophiques sur des
serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif
pour récupérer le contenu d'Exchange :-((((
Arf, pas glop ça, effectivement. Mais, bon, SBS, je n'ai jamais eu de
bonnes relations avec lui...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Le clonage, c'est pas un problème, ça se résoud d'un coup de NewSID.
C'est vrai.
En revanche, j'ai déjà vu des situations catastrophiques sur des serveurs SBS uniques, et quand t'as paumé ton domaine, c'est sportif pour récupérer le contenu d'Exchange :-((((
Arf, pas glop ça, effectivement. Mais, bon, SBS, je n'ai jamais eu de bonnes relations avec lui...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
