J'ai déjà posé les questions sur le forum Debian mais n'ai reçu aucune
réponse permettant de me dépanner, jusqu'à présent.
En préambule : je fais tourner plusieurs machines sous Ouindo$e et
Ubuntu. J'utilise Thunderbird sur les 2 systèmes et peut donc, au gré de
mes déplacements, coller/copier la BdD (les profils, carnets d'adresses
et courrier, quoi) d'une machine à l'autre et ainsi en disposer à tout
moment, quelle que soit la machine utilisée.
Icedove étant le log de messagerie remplaçant Thunderbird, je l'ai donc
installé sur ma Lenny puisqu'elle devra également me suivre dans mes
déplacements. Seulement voilà : le même copier/coller ne donne rien ;
pire : à partir du moment où mes profils sont installés dans le
répertoire ad hoc, impossible d'ouvrir Icedove qui répond qu'il est déjà
utilisé ... alors qu'il n'a même pas encore été ouvert. Je redémarre le
système : même punition. Lorsque je démarre avec un Icedove vierge, pas
de problème : il s'ouvre mais ne contient évidemment aucun profil et ne
m'est d'aucun secours tant que je n'ai pas installé ma BdD ... qui fait
600 Mo, tout de même. Mon profiles.ini est pourtant correct.
En désespoir de cause, je tente l'installation de Thunderbird mais il
n'existe qu'une archive tar.bz2. Les dépôts Debian ne proposant pas ce
logiciel (dommage : ce serait plus facile), je l'ai téléchargé à partir
du serveur Mozilla. Je décompresse puis je lance l'install par :
debian:/home/docanski# cd /home/docanski/thunderbird
debian:/home/docanski/thunderbird# ./configure
bash: ./configure: Aucun fichier ou répertoire de ce type
et pourtant le chemin est correct !
J'ajoute que le readme donne un lien pour les infos d'installation mais
celui-ci attérit automatiquement sur la page de téléchargement de
Mozilla ! Impossible donc d'installer Thunderbird. :-(
Alors, si une bonne âme peut me donner la solution soit pour Icedove,
soit pour Thunderbird, je suis preneur.
Merci d'avance !
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits. Et j'aimerais savoir pourquoi. Serait-ce que Debian est plus sécurisée qu'Ubuntu sur ce plan ? Serait-ce le cas avec d'autres BdD d'applications pourtant accessibles aux utilisateurs et pas seulement à root ?
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de proprietaire/droits etendus comme n'importe quel systeme unix. Le comportement par défaut sous Debian et d'attribuer tous les fichiers et repertoires à root en lecture/ecriture exclusivement par root. Je te l'accorde, c'est assez... "conservative" comme ils disent de l'autre coté de l'atlantique. Si ce comportement ne te plait pas, tu peux jouer avec les options de montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
-- Rico
docanski wrote:
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e
vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que
d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et j'aimerais savoir pourquoi. Serait-ce que Debian est plus sécurisée
qu'Ubuntu sur ce plan ? Serait-ce le cas avec d'autres BdD
d'applications pourtant accessibles aux utilisateurs et pas seulement à
root ?
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de
proprietaire/droits etendus comme n'importe quel systeme unix.
Le comportement par défaut sous Debian et d'attribuer tous les fichiers
et repertoires à root en lecture/ecriture exclusivement par root. Je te
l'accorde, c'est assez... "conservative" comme ils disent de l'autre
coté de l'atlantique.
Si ce comportement ne te plait pas, tu peux jouer avec les options de
montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits. Et j'aimerais savoir pourquoi. Serait-ce que Debian est plus sécurisée qu'Ubuntu sur ce plan ? Serait-ce le cas avec d'autres BdD d'applications pourtant accessibles aux utilisateurs et pas seulement à root ?
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de proprietaire/droits etendus comme n'importe quel systeme unix. Le comportement par défaut sous Debian et d'attribuer tous les fichiers et repertoires à root en lecture/ecriture exclusivement par root. Je te l'accorde, c'est assez... "conservative" comme ils disent de l'autre coté de l'atlantique. Si ce comportement ne te plait pas, tu peux jouer avec les options de montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
-- Rico
Sergio
Eric Belhomme a écrit :
docanski wrote:
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers "étrangers". Par exemple, il y a bien gestion des droits sous NTFS, néanmoins, ce n'est pas utilisé sous Linux.
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de proprietaire/droits etendus comme n'importe quel systeme unix. Le comportement par défaut sous Debian et d'attribuer tous les fichiers et repertoires à root en lecture/ecriture exclusivement par root. Je te l'accorde, c'est assez... "conservative" comme ils disent de l'autre coté de l'atlantique. Si ce comportement ne te plait pas, tu peux jouer avec les options de montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
Normalement, par défaut, Ubuntu attribue le volume à root, avec les droits rwx à tous. Mais c'est par défaut le umask/dmask du process qui monte tout ça. Je ne sais pas où ça se règle...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Eric Belhomme a écrit :
docanski wrote:
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e
vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que
d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers "étrangers". Par exemple, il y a bien gestion des droits sous
NTFS, néanmoins, ce n'est pas utilisé sous Linux.
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de
proprietaire/droits etendus comme n'importe quel systeme unix.
Le comportement par défaut sous Debian et d'attribuer tous les fichiers
et repertoires à root en lecture/ecriture exclusivement par root. Je te
l'accorde, c'est assez... "conservative" comme ils disent de l'autre
coté de l'atlantique.
Si ce comportement ne te plait pas, tu peux jouer avec les options de
montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
Normalement, par défaut, Ubuntu attribue le volume à root, avec les droits rwx à tous. Mais c'est par défaut le umask/dmask du
process qui monte tout ça. Je ne sais pas où ça se règle...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers "étrangers". Par exemple, il y a bien gestion des droits sous NTFS, néanmoins, ce n'est pas utilisé sous Linux.
Ca vient tout simplement du fait que FAT (et FAT32) n'a pas de notion de proprietaire/droits etendus comme n'importe quel systeme unix. Le comportement par défaut sous Debian et d'attribuer tous les fichiers et repertoires à root en lecture/ecriture exclusivement par root. Je te l'accorde, c'est assez... "conservative" comme ils disent de l'autre coté de l'atlantique. Si ce comportement ne te plait pas, tu peux jouer avec les options de montage (man mount, section fat)
Pour ce qui conerne Ubuntu, j'en sais rien, j'utilise pas...
Normalement, par défaut, Ubuntu attribue le volume à root, avec les droits rwx à tous. Mais c'est par défaut le umask/dmask du process qui monte tout ça. Je ne sais pas où ça se règle...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Erwan David
Sergio écrivait :
Eric Belhomme a écrit :
docanski wrote:
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers "étrangers". Par exemple, il y a bien gestion des droits sous NTFS, néanmoins, ce n'est pas utilisé sous Linux.
Il y a là 2 problèmes :
1) la base des utilisateurs sur un disque étranger n'a rien à voir avec la base locale. Il n'y a aucune raison que l'utilisateur 501 de mon mac soit le 501 de ma debian ou de mon freeBSD
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je ne suis pas sûr que le reverse engeneering permettait une gestion correcte des droits.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
En effet. Assez curieusement, le copier/coller des profils de
Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce
problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se
pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers
"étrangers". Par exemple, il y a bien gestion des droits sous NTFS,
néanmoins, ce n'est pas utilisé sous Linux.
Il y a là 2 problèmes :
1) la base des utilisateurs sur un disque étranger n'a rien à voir avec
la base locale. Il n'y a aucune raison que l'utilisateur 501 de mon mac
soit le 501 de ma debian ou de mon freeBSD
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je
ne suis pas sûr que le reverse engeneering permettait une gestion
correcte des droits.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
En effet. Assez curieusement, le copier/coller des profils de Ouindo$e vers Ubuntu et vice et versa ne souffrent pas de ce problème alors que d'Ubuntu vers Debian ou Ouine vers Debian se pose ce problème de droits.
Et également, que Linux se fout des droits des systèmes de fichiers "étrangers". Par exemple, il y a bien gestion des droits sous NTFS, néanmoins, ce n'est pas utilisé sous Linux.
Il y a là 2 problèmes :
1) la base des utilisateurs sur un disque étranger n'a rien à voir avec la base locale. Il n'y a aucune raison que l'utilisateur 501 de mon mac soit le 501 de ma debian ou de mon freeBSD
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je ne suis pas sûr que le reverse engeneering permettait une gestion correcte des droits.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Eric Belhomme
Sergio wrote:
Mais que l'utilisateur 501 de ma Debian soit le même que l'utilisateur 501 de ta Debian ? Il me semble de plus que, suivant la distribution, l'attribution par défaut des utilisateurs est différente...
C'est vrai pour les utilisateurs "systemes" créés par défaut. Mais ce n'est pas vrai pour les utilisateurs normaux. Sur Debian, le 1er utilisateur créé obtient l'uid 1000, le 2eme l'uid 1001, etc. Sur RHEL, le 1er utilisateur obtien 500, etc.
Bref, sans annuaire centralisé (NIS ou LDAP) tu n'as presque aucune chance d'avoir un truc uniforme
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je ne suis pas sûr que le reverse engeneering permettait une gestion correcte des droits.
Le vrai probleme (en tout cas ca l'a été pendant longtemps, mais ca n'est plus tout a fait vrai maintenant que la majorité des systemes de fichiers unix supporent les ACL POSIX) est de faire la correspondance entre les ACLs NTFS et les droits unix.
-- Rico
Sergio wrote:
Mais que l'utilisateur 501 de ma Debian soit le même que l'utilisateur 501 de ta Debian ? Il me semble de plus que, suivant la
distribution, l'attribution par défaut des utilisateurs est différente...
C'est vrai pour les utilisateurs "systemes" créés par défaut. Mais ce
n'est pas vrai pour les utilisateurs normaux.
Sur Debian, le 1er utilisateur créé obtient l'uid 1000, le 2eme l'uid
1001, etc.
Sur RHEL, le 1er utilisateur obtien 500, etc.
Bref, sans annuaire centralisé (NIS ou LDAP) tu n'as presque aucune
chance d'avoir un truc uniforme
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je
ne suis pas sûr que le reverse engeneering permettait une gestion
correcte des droits.
Le vrai probleme (en tout cas ca l'a été pendant longtemps, mais ca
n'est plus tout a fait vrai maintenant que la majorité des systemes de
fichiers unix supporent les ACL POSIX) est de faire la correspondance
entre les ACLs NTFS et les droits unix.
Mais que l'utilisateur 501 de ma Debian soit le même que l'utilisateur 501 de ta Debian ? Il me semble de plus que, suivant la distribution, l'attribution par défaut des utilisateurs est différente...
C'est vrai pour les utilisateurs "systemes" créés par défaut. Mais ce n'est pas vrai pour les utilisateurs normaux. Sur Debian, le 1er utilisateur créé obtient l'uid 1000, le 2eme l'uid 1001, etc. Sur RHEL, le 1er utilisateur obtien 500, etc.
Bref, sans annuaire centralisé (NIS ou LDAP) tu n'as presque aucune chance d'avoir un truc uniforme
2) Pour NTFS, la spec complète n'est sorti qu'il y a quelques mois. Je ne suis pas sûr que le reverse engeneering permettait une gestion correcte des droits.
Le vrai probleme (en tout cas ca l'a été pendant longtemps, mais ca n'est plus tout a fait vrai maintenant que la majorité des systemes de fichiers unix supporent les ACL POSIX) est de faire la correspondance entre les ACLs NTFS et les droits unix.
