Hello,
toujours dans mon projet (qui est finalement en prod parce que suffisant pour l'instant) de cluster HA Samba, j'avais des problèmes d'ACL Posix (voir le forum: http://linuxfr.org/forums/12/7114.html(...) Samba et ACL Posix.)
Je précise que l'ensemble tourne sous Debian Sarge et que dans le pot pourri on trouve les couches suivantes:
- Samba 3.0.10
- OpenLDAP 2.1 (over outdated mais stable donc on ne se plaint pas)
- Heartbeat
- DRBD 0.7.7
- CUPS
- LVM2 + XFS +Quotas
- smbldap-tools
Aujourd'hui, je contacte un de mes "co-admins" pour mettre en place les droits qui vont bien sur un répertoire Samba spécifique vu que, comme indiqué dans le message du forum, seul le compte root pouvait modifier les ACL des fichiers ne lui appartenant pas.
Quelle ne fût pas ma surprise lorsqu'il m'a répondu: "C'est OK, j'ai réglé les histoires de droits tout seul !"...
J'ai voulu vérifier quand même: je me pointe sur le répertoire par un client Win2K et je mate les onglets de sécurité. En effet, les droits ont été changés sur le répertoire et les fichiers alors que tout ce beau monde appartient à root !
Bon, je mate directement sur le serveur (getfacl) et tout correspond pile poil !!!!
Je supprime les ACL d'un fichier pour test, vérifie bien que le fichier appartient à root et je demande à mon collègue de refaire la manip (client win2k aussi) en direct: et ni plus ni moins, il me recolle des ACL en veux-tu en voilà comme si de rien n'était....
Je n'y comprends plus rien: je n'ai fait aucun changement sur le serveur depuis le déploiement où j'avais noté mes problèmes d'ACL qui m'ont paru logiques: sous Unix, seul root peut changer le propriétaire des fichiers. De même, la doc de setfacl précise bien que seul root est l'utilisateur qui peut ajouter des ACL sur des fichiers ne lui appartenant pas (au sens Posix du terme et non au sens NTFS). La seule chose qui, potentiellement a légèrement bougé, c'est le contenu de mon arbre LDAP (et encore: j'ai ajouté quelques users de base et quelques groupes).
Donc, je ne sais plus quoi penser. Néanmoins, pour la journée de demain, je vais me concoter quelques tests pour voir d'où ça vient parce que c'est comme si mon problème du début n'existait plus (ce qui est une bonne nouvelle: je vais pouvoir déléguer mes attributions de droits à mes collègues donc moins de taff lourdingue pour moi):
- Première supposition: sous Unix, seul root peut faire ce machin; or, chez moi, samba est lancé par root (mais dans ce cas, pourquoi j'ai eu des problèmes au début)!
- Deuxième supposition: peut-être que tout vient de mon arbre LDAP et auquel cas, il faut que je vois où j'ai pu me tromper.
Bon, les tests pour demain:
- Refaire un test d'attribution des droits avec des users du groupe des administrateurs Samba(différent de root).
- Faire ce test sur des répertoires nouvellement créés
- Refaire le test avec des répertoires sans ACL par défaut et avec
- Créer un groupe tout neuf et des users et voir si on peut reproduire les effets précédents.
- Voir si le fait d'ajouter les SID dans la définition du groupe (LDAP: PosixGroup + SambaGroup) ne règle pas la question.
Ma conclusion du jour: faut que je retourne bosser au plus vite pour éclairci ce mystère...
# Une idée
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Samba tournant en root si samba pense que l'utilisateur à le droit (il est administrateur) il fera le changement (en temps que root).
# Sympa
Posté par mcben . Évalué à 4.
Tu as documenté ce que tu as fait ? Tu peux nous en faire profiter ? Ou bien les docs que tu as utilisé..
Merci d'avance _o/
# Extended Attributes ?
Posté par Guillaume D. . Évalué à 1.
Pour t'aider, un petit
getfacl
et ls -a
nous aiderait pour te repondre.
Ensuite, a tu compiler XFS avec les Extended ATTRibute et mis l'option coreespondante qui va bien dans smb.conf ?
(mappage des flags DOS : READONLY, SYSTEM, ARCHIVE dans les Extend Attributes, plutot que l'ancienne bidouille "rwxrwxrwx", ce qui expliquerait tes problèmes.
A+
( DRBD c'est bien mangez en ... )
une doc de principe des droits avec ACL http://www.linuxplusvalue.be/mylpv.php?id=153(...)
[^] # Re: Extended Attributes ?
Posté par L. R. . Évalué à 2.
Je m'intéresse à ce genre de cluster HA, et j'étais tombé sur ENDB pour faire l'équivalent de DRBD (il y avait eu un article sur le sujet dans Linux Magazin (de)). Est-ce que tu as eu une expérience avec ? Se valent-ils ?
Merci :)
[^] # Re: Extended Attributes ?
Posté par Guillaume D. . Évalué à 1.
tu as un tres bon article pour drbd.
J'ai en prod 1 (enfin 2) serveurs avec DRBD, c'est que du bonheur, temps d'indisponibilité maxi : 15 secondes ....
DRBD + EXT3 (journalisé) + Heartbeat .... miam ...
A+
[^] # Re: Extended Attributes ?
Posté par Yves Agostini (site web personnel) . Évalué à 1.
Je suis en train d'en mettre 2 autres en places (4 machines).
http://www.crium.univ-metz.fr/docs/system/drbd/(...)
# Et ton collègue ?
Posté par jerome (site web personnel) . Évalué à 2.
# Une question à 1000 euros au passage...
Posté par bobert . Évalué à 2.
Est-il possible de passer de Active Directory + authentification kerberos + GPO à Samba + openldap ?
[^] # Re: Une question à 1000 euros au passage...
Posté par Nap . Évalué à 2.
tu auras toujours besoin d'un contrôleur de domaine A.D. si tu veux un réseau A.D. En tout cas il y a quelques mois c'était comme ça.
[^] # Re: Une question à 1000 euros au passage...
Posté par bobert . Évalué à 2.
merci de ta réponse, mais j'ai un peu de mal à saisir... je ne connais pas grand-chose à tout ça (je rapporte ici le problème d'un ami), il me semblait que samba pouvait faire office de contrôleur de domaine.
Du coup, sans Active Directory, peut-on se rapprocher le plus possible de la configuration initiale avec Samba + OpenLdap, ou dans le cas contraire, qu'est-ce qui n'a pas encore d'alternative côté libre ?
[^] # Re: Une question à 1000 euros au passage...
Posté par Nap . Évalué à 2.
En résumé :
Réseau NT4 : tu peux te passer complètement des serveurs MS
Réseau W2K : tu dois garder le contrôleur de domaine A.D. Tu peux, avec Samba, joindre un domaine Active Directory en tant que serveur membre, pour par exemple partager des ressources, mais tu auras toujours besoin d'un contrôleur MS.
[^] # Re: Une question à 1000 euros au passage...
Posté par bobert . Évalué à 2.
(ce qui est surtout clair, c'est que les gens que je connais sont pied et poing liés à Microsoft...)
# UP
Posté par Médéric RIBREUX (site web personnel) . Évalué à 1.
bon ben ça marche comme il faut finalement !
Donc, les seuls changements que j'ai fait sont la mise en place d'ACL par défaut (avec dedans les droits en rwx pour les administrateurs du domaine : le groupe Posix 512 et le groupe Samba dont le SID se termine par 512) et surtout, ajouter des users à ce groupe !!!
Seuls les utilisateurs de ce groupe peuvent changer les ACL sur les fichiers et les répertoires(qui ne leur appartiennent pas). J'ai essayé avec un autre utilisateur hors de ce groupe, il ne peut pas le faire. Par contre, dès que je l'ajoute au groupe 512, pas de problèmes. Dans l'annuaire LDAP, l'ajout ou non du SambaSIDList n'a aucun effet.
De plus, pour un autre groupe que le 512 (un groupe samba d'utilisateurs d'un secteur par exemple), même si je mets les droits en ACL par défaut sur un répertoire , en contrôle total (rwx) pour ce groupe, un utilisateur de ce groupe ne peut pas modifier les ACL.
Tout cela se passe dans Samba et uniquement par Samba. Les ACL Posix sous Linux ne permettent pas ce genre de choses. Pour résumer, dans Samba, le groupe 512 peut modifier les ACL de tous les fichiers ce qui est une bonne chose.
[^] # Re: UP
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
[^] # Re: UP
Posté par Médéric RIBREUX (site web personnel) . Évalué à 2.
vérification faite, c'est ça !!!
Franchement, j'ai honte d'avoir remué tout un foin pour si peu.
Merci à tous pour votre collaboration.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.