Debian vs Fedora : FIGHT !!! - Page 1

... pour la possession de mes données.

J'ai donc une Debian et une Fedora, pas dans des VM.
Quand sous l'une, je me donne les droits sur mes partitions de données, ben sur l'autre, je perds les droits.

Etant entendu qu'il n'est pas question que j'ouvre les droits maximum (cad r/o pour n'importe qui, quelque soit le compte et le groupe), faut-il absolument que mes users sur les deux distribs aient au moins le même GID pour pouvoir se partager les données ?
Idéalement, faudrait-il que mes deux comptes aient même GID/UID pour simplifier les choses et réduire les permissions au minimum ?

Folco (./1) :
... pour la possession de mes données.

J'ai donc une Debian et une Fedora, pas dans des VM.
Quand sous l'une, je me donne les droits sur mes partitions de données, ben sur l'autre, je perds les droits.
Etant entendu qu'il n'est pas question que j'ouvre les droits maximum (cad r/o pour n'importe qui, quelque soit le compte et le groupe), faut-il absolument que mes users sur les deux distribs aient au moins le même GID pour pouvoir se partager les données ?

oui

Idéalement, faudrait-il que mes deux comptes aient même GID/UID pour simplifier les choses et réduire les permissions au minimum ?

oui

Plus exactement, même user id est plus utile que même group id, et probablement plus facile à mettre en place, mais le mieux reste d'avoir une synchronisation pour uid et gid.

PS: Sinon y'a aussi la solution de jeter fedora aux ordures et de broyer le dvd durant un rituel satà la gloire de dieu.

Ok, merci, même si j'ai pas de DVD Fedora, installation par disque dur powa.

Folco (./1) :
... pour la possession de mes données.

J'ai donc une Debian et une Fedora, pas dans des VM.
Quand sous l'une, je me donne les droits sur mes partitions de données, ben sur l'autre, je perds les droits.

Etant entendu qu'il n'est pas question que j'ouvre les droits maximum (cad r/o pour n'importe qui, quelque soit le compte et le groupe), faut-il absolument que mes users sur les deux distribs aient au moins le même GID pour pouvoir se partager les données ?
Idéalement, faudrait-il que mes deux comptes aient même GID/UID pour simplifier les choses et réduire les permissions au minimum ?

C'est tout à fait normal, vu que ce n'est pas le login qui a les droits mais le UID / GID. Je ne vois pas trop comment on peut espérer faire autrement

Ok, j'avais jamais été confronté à ce problème, j'avais du n'installer que des distribs qui attribuaient des couples GID/UID de 500:500 au premier compte utilisateur. Il se trouve que c'est le cas de Fedora, mais Debian mets 1000:1000 par défaut.

Un solution serait d'avoir une machine qui reagit en tant que serveur de comptes pour y administrer tous les logins communs aux deux machines (c'est a dire presque tout sauf les root et logins system divers). Il me semble que NIS peut repondre a tes besoins (meme si pour 2 machines tu peux tres bien configurer tout a la main en maintenant une synchro, mais c'est chiant a la longue et pas conventionnel).

Hmm mais ce genre de truc va fonctionner si tu utilises des distributions complètement différentes, et dont les noms et numéros des groupes systèmes seront différents ?
Genre si ton utilisateur est associé à "plugdev mysql cofeemaker" ou que sais-je encore, il va se passer quoi ?

Bah oui, c'est fait pour (les groupes sont aussi gérés par le serveur de comptes)
Je ne connais pas NIS, mais LDAP le fait, aussi bien qu'OpenDirectory ou ActiveDirectory.

Par contre, utiliser un serveur de comptes pour deux distrib sur la même machine, c'est un peu... bourrin, non ?

et heu editer /etc/passwd sur l'une des distro, nan? strop simple?

liquid (./6) :
Un solution serait d'avoir une machine qui reagit en tant que serveur de comptes pour y administrer tous les logins communs aux deux machines (c'est a dire presque tout sauf les root et logins system divers). Il me semble que NIS peut repondre a tes besoins (meme si pour 2 machines tu peux tres bien configurer tout a la main en maintenant une synchro, mais c'est chiant a la longue et pas conventionnel).

GoldenCrystal (./7) :
Hmm mais ce genre de truc va fonctionner si tu utilises des distributions complètement différentes, et dont les noms et numéros des groupes systèmes seront différents ?

Oui, c'est justement fait pour. NIS/YP (ou, de façon un peu plus récente et plus standardisée, x500 ou sa version allégée LDAP ; NIS est quand même un peu obsolète ^^) permettent d'avoir un référentiel usagers unique (x500/LDAP étant plus souple et permettant en plus de décrire autre chose que des comptes utilisateurs) pour des systèmes différentes. Par contre, c'est un peu surdimensionné pour une utilisation domestique (sauf si Martial a un petit serveur qui tourne en permanence). A mon avis, vu son cas, il devrait plutôt faire une synchronisation (manuelle ou par script géré au niveau de l'init) du fichier passwd (pour les utilisateurs/groupes ayant un ID dans la zone des usagers physiques).

L'avantage de LDAP, c'est qu'il permet d'authentifier les utilisateurs pour tout plein de services
J'utilise OpenDirectory (basé sur LDAP) pour le wifi, le web, le ftp, les calendriers, etc... Quand on a un serveur domestique, c'est bien pratique

Flanker (./8) :
Bah oui, c'est fait pour (les groupes sont aussi gérés par le serveur de comptes)
Je ne connais pas NIS, mais LDAP le fait, aussi bien qu'OpenDirectory ou ActiveDirectory.

Par contre, utiliser un serveur de comptes pour deux distrib sur la même machine, c'est un peu... bourrin, non ?

Oui mais justement, mettons que debian utilise un groupe "audio" avec id n°13 et fedora "sound" avec n°19... Tu fais comment la mise en relation ?
C'est juste ce truc que je comprends pas. (Nil a aussi le droit de répondre )

Par contre oui, de toutes façons c'est surdimensionné, et sans intérêt sachant que Folco n'a probablement pas plus de deux utilisateurs (non systèmes) sur sa machine.

Mais non, le gid est donné par LDAP, pas par debian ou fedora. Et réciproquement, quand tu vas faire un chown folco_:audio /home/folco , Debian et Fedora vont demander au LDAP quels sont les uid/gid qui correspondent.

Quand le système va tomber sur fichier avec uid=42/gid=23, il va demander au LDAP à qui correspond le 42, à quoi correspond le 23.


(en revanche, tu peux très bien avoir les deux systèmes qui cohabitent : si LDAP ne sait pas à qui correspond 42, Debian va regarder dans son /etc/passwd si lui le sait, ou le contraire)

edit: j'avais pas fait gaffe que tu parlais de deux groupes différents sound et audio. Mais là, je ne vois pas du tout le problème, en fait
Soit c'est le même groupe, dans ce cas Folco l'appelle de la même façon, soit c'est pas le même groupe

Oui mais la distribution, par défaut n'est pas configurée pour utiliser des noms de groupe non standard, et les GID associés aux noms a priori on s'en fout un peu (pas complètement sur). Donc ça voudrait dire que tu dois tout bidouiller dans ton système avant de mettre ça en place non ?
Genre pour dire à udev que le groupe "patate" est maintenant le groupe "tutu" commun a l'annuaire [et qu'il aura l'id 414 en principe, au lieu de 666 précédemment].
Car tu as une association fichier <=> uid:gid mais aussi user <=> group. Donc le serveur doit (à priori ?) connaitre les groupes, y compris systèmes, à associer à l'utilisateur, mais le système doit connaître les bons numéros et les noms correspondants pour que tout fonctionne bien au niveau du système de fichier.
Ça me parait un peu bancal mais bon y'a un truc que je dois pas voir

J'ai toujours un souci... J'ai laissé mon compte avec un GID/UID de 500/500 sous Fedora.

J'ai changé /etc/group et mis 500:x:500:folco sur ma Debian.

J'ai fait un chown -R 500:500 /mnt/* sous Debian.

J'ai maintenant un accès complet sous Fedora, mais juste un accès en lecture sous Debian. Qu'ai-je raté ?

Edit : cross

Bon bah Flan a répondu
En fait, quand tu définis l'ordre de recherche d'authentification (paramétrage de pam), tu indiques un ordre de recherche. Si l'information n'est pas trouvée dans le premier référentiel, on passe au suivant. Tu peux très bien avoir la gestion des groupes qui se fait dans l'ordre suivant : ldap - /etc/groups/ - une autre méthode d'authentification (kerberos, utilisateur mysql ou que sais-je, pourvu qu'il y ait un composant pour pam).
Ca permet plein de choses :
- Ne pas mettre d'usager root dans l'annuaire (donc si je me fais pirater mon annuaire, personne ne pourra passer en root)
--> A l'authentification, pour root, comme il ne le trouve pas dans l'annuaire, il va dans /etc/passwd /etc/shadow

- Mettre un usager root dans l'annuaire (donc je peux changer très rapidement et facilement mon mot de passe root et ça a une incidence directe sur toutes mes machines)
--> En cas de rupture de service de l'annuaire, je peux toujours me connecter avec le compte root donné dans /etc/passwd

En fait, pam est un outil particulièrement puissant (mais un peu mal foutu parfois, et certains connecteurs sont franchement buggés). Il te permet de gérer les méthodes d'authentification, les priorités, le fallback, ce à quoi tu t'authentifies (tu peux par exemple associer un montage smb/cifs à une ouverture de session Linux, le mot de passe est récupéré directement au moment de l'authentification, pas besoin d'avoir un trou de sécu avec le mot de passe en clair dans fstab/à retaper à chaque montage), suivant le procédé d'authentification (console, ssh, etc.).

GoldenCrystal (./14) :
Oui mais la distribution, par défaut n'est pas configurée pour utiliser des noms de groupe non standard, et les GID associés aux noms a priori on s'en fout un peu (pas complètement sur). Donc ça voudrait dire que tu dois tout bidouiller dans ton système avant de mettre ça en place non ?
Genre pour dire à udev que le groupe "patate" est maintenant le groupe "tutu" commun a l'annuaire [et qu'il aura l'id 414 en principe, au lieu de 666 précédemment].
Car tu as une association fichier <=> uid:gid mais aussi user <=> group. Donc le serveur doit (à priori ?) connaitre les groupes, y compris systèmes, à associer à l'utilisateur, mais le système doit connaître les bons numéros et les noms correspondants pour que tout fonctionne bien au niveau du système de fichier.
Ça me parait un peu bancal mais bon y'a un truc que je dois pas voir

Là, on est d'accord, ça va être le bordel

Mais je pense que la bonne solution, c'est de laisser les groupes du système être gérés par le système, et ne mettre que les utilisateurs en LDAP (c'est la solution la plus courante, si je ne m'abuse). Tu peux définir avec pam plusieurs moyens d'authentification, qui seront successivement essayés pour reconnaître un utilisateur.

Folco (./15) :
J'ai maintenant un accès complet sous Fedora, mais juste un accès en lecture sous Debian. Qu'ai-je raté ?

C'est un problème de droits utilisateur, c'est sûr ? Pas de montage ? (juste pour être sûr).

Folco > commence par mettre en place un serveur LDAP

./15 > Ben, /etc/group c'est pour les informations de groupe donc quand tu fais un chown 500:500 y'a que le 500 du groupe qui est compris par le système par la suite, non ?

GoldenCrystal (./20) :

./15 > Ben, /etc/group c'est pour les informations de groupe donc quand tu fais un chown 500:500 y'a que le 500 du groupe qui est compris par le système par la suite, non ?

Bien vu (hint pour Folco : /etc/passwd )

Flanker (./19) :
Folco > commence par mettre en place un serveur LDAP

Faut encore qu'il ait une machine qu'il puisse dédier à ça... et partager les données un serveur ldap entre deux distributions me semble particulièrement dangereux (le format des fichiers de données varie d'une version à l'autre).

Flanker (./17) :
Là, on est d'accord, ça va être le bordel

Mais je pense que la bonne solution, c'est de laisser les groupes du système être gérés par le système, et ne mettre que les utilisateurs en LDAP (c'est la solution la plus courante, si je ne m'abuse). Tu peux définir avec pam plusieurs moyens d'authentification, qui seront successivement essayés pour reconnaître un utilisateur.

Donc, en gros, pam assignerait de manière "dynamique" les groupes à l'utilisateur ? (genre audio, video, plugdev, cdrom, ...)

bah rien ne t'empêche dans le ldap de dire que l'utilisateur fait partie des groupes 42, 23 et 53, même s'ils ne sont pas eux-mêmes gérés par le LDAP.

./22 > Hmmm, de mémoire non, en effet... Disons que dans ton annuaire, tu vas associer des groupes à ton utilisateur

mettons que tu aies :
Fedora :
110 -> audio
130 -> mount
135 -> xuser

et
Debian
50 -> sound
100 -> umount
200 -> xuser

dans l'annuaire, tu vas coller les groupes 50, 100, 110, 130, 135 et 200 à l'utilisateur
Mais ça va effectivement chier dans le cas où un gid est utilisé pour deux groupes différents :/ Là, il faut uniformiser la gestion des groupes dans les distributions (ou tout déléguer à l'annuaire mais, de toutes façons, ça implique d'uniformiser les gid)

Nil (./21) :
Bien vu (hint pour Folco : /etc/passwd )

Ok, je m'y plonge, merci à tous.

A priori, ce n'est pas un problème de montage, je n'y ai pas touché, j'ai ça dans mes fstab :
/dev/sdxy /mnt/Data ext3 defaults 0 0


edit -> bien vu...
$ cat /media/debian/etc/passwd
Je semble encore être en 1000:1000

Erf... quand je change le 1000:1000 dans /etc/passwd, il me met "unknown hostname" quand je me log... La man de passwd me renvoye vers la commande passwd... vers où chercher ?

Edit : t'as ptetre des choses à changer aussi dans /etc/shadow pour le coup
Edit 2 : Non, j'ai rien dit, il n'y a pas d'uid dans shadow :/

"unknown hostname" en tant qu'erreur au login ou juste un truc qui s'affiche ?
C'est peut-être un patch spécial à debian qui fait ça... ou une fonctionalité spéciale de pam...
Et si c'est le cas je saurais pas dire quoi car mon système n'est pas un debian (même si gentoo est assez proche) et que j'ai dégagé pam parce que ça sert à rien et que ça rend trop facilement le système non bootable.
En tout cas j'ai déjà fait la manipulation (pour synchroniser UID Gentoo -> UID Mac OS X) et ça a marché sans le moindre soucis.
Tu as essayé de te loger en root pour faire quelques vérifications, genre si le chown fonctionne bien, etc ?
D'ailleurs en fait, peut-être que tu as oublié de synchroniser ton ~ debian avec le nouveau UID ?

Putain pas con ...

bon, ça marche toujours pas.

Sur Debian, j'ai ça dans mon /etc/group :
500:x:500:folco

et dans /etc/passwd :
folco:500:500:folco,,,:/home/folco:/bin/bash

Sur Fedora, j'ai ça dans /etc/group :
folco:x:500:

et dans /etc/passwd :
folco:x:500:500::/home/folco:/bin/bash

Les deux fichiers devraient avoir la même forme dans les deux distribs ? En tout cas, sur Fedora, tout marche comme attendu.