Bonjour.
Veuillez excuser ce (presque ?) hors sujet, ceci se passe sous AIX et non sous GNU/Linux, mais comme il s'agit avant tout de configuration de Samba, j'essaye. (Et puis si je n'y arrive pas, les instances supérieures opterons pour une solution propriétaire :-p )
Voilà la problématique. Je dois migrer d'un serveur (ancien) à un autre (nouveau) un répertoire partagé via Samba. Le problème est que les protections mise en place sur ancien ne fonctionnent plus sur nouveau. C'est sans doute dû au changement de version de Samba.
Voici les deux configurations.
ancien : Samba 2.0.7 sur AIX 4.3.1.0
Dans smb.conf :
[global]
workgroup = GROUPE
server string = Samba Server
guest account = nobody
log file = /var/samba/log/log.%m
max log size = 50
security = SERVER
password server = SERVEURMOTDEPASSE
socket options = TCP_NODELAY
Exemple de partage :
[hpgl]
comment = fichiers concepteurs
path = /hpgl
public = no
writable = no
browsable = no
valid users = @concept
force directory mode = 0775
Ici on partage en lecture seule uniquement aux utilisateurs appartenant au groupe concept.
nouveau : Samba 3.0.4 sur AIX 5.2.0.0
Dans smb.conf :
[global]
workgroup = AUTREGROUPE
server string = Samba 3.0.4.0
security = SHARE
encrypt passwords = Yes
log file = /usr/local/samba/var/log.%m
mangle case = Yes
display charset = UTF8
Avec cette configuration, un partage du type suivant fonctionne normalement :
[test-public]
comment = Test de répertoire partagé à tout le monde
path = /test
public = yes
writable = no
browsable = yes
Par contre si l'on veut restreindre l'accès comme sur l'ancien serveur :
[test-prive]
comment = Test de répertoire protégé
path = /test
public = no
writable = no
browsable = yes
valid users = @concept
force directory mode = 0775
le répertoire est bien protégé, mais tellement bien que même les gens qui sont dans le groupe concept ne peuvent pas y accéder (il demande un mot de passe).
Notez qu'outre la différence de version de Samba, la principale différence entre les deux configuration et que le mode de sécurité est SERVER sur ancien et SHARE sur nouveau. En effet, si je mets les mêmes paramètres de sécurité sur nouveau (security=SHARE et password server) ça bloque complètement l'accès à la liste des partages.
Peut-être que cette différence est à l'origine du problème, mais le chapitre concerné de la doc de samba (http://us3.samba.org/samba/docs/man/Samba-HOWTO-Collection/A(...) ne mentionne pas un mode de sécurité recommandé.
Quelqu'un aurait-il un conseil à donner, une idée sur la question ? Si oui, merci d'avance, sinon merci quand même d'avoir lu jusqu'ici. :-)
# Ca me rappelle quelque chose....
Posté par Gyro Gearllose . Évalué à 2.
Pour la partie le mode de sécurité est SERVER sur ancien et SHARE sur nouveau, il faut récupérer le ssid sur ancien et le remettre sur nouveau. Je ne me souviens plus de la manip, mais une recherche sur gogole devrait donner de bons résultats rapidement.
Pour le problème du répertoire protégé qui l'est trop, comme ça, à brûle pourpoint, il me semble que vouloir écrire dans un partage dont la directive writeable est positionnée à no ne peut pas fonctionner....
Voilà, en espérant que ça aide.
[^] # Re: Ca me rappelle quelque chose....
Posté par Naha (site web personnel) . Évalué à 2.
Hum, il ne s'agit pas d'écrire, mais bien de lire : on a une demande de mot de passe quand on cherche à "ouvrir" un partage.
Ceci dit remplacer "valid users" par "write list" dans mon exemple, même s'il y a "writable = no", devrait permettre aux membres de concept d'écrire dans le partage. C'est comme ça que ça marchait sur ancien en tout cas...
[^] # Re: Ca me rappelle quelque chose....
Posté par Gyro Gearllose . Évalué à 3.
C'est l'identifiant du serveur...
On le récupère avec :
$ net getlocalsid
Pour le reste, oublie, j'ai lu et répondu trop vite.
[^] # Re: Ca me rappelle quelque chose....
Posté par Naha (site web personnel) . Évalué à 2.
Je vais regarder ça demain mais ça a l'air mal barré : la commande net n'existe pas sur ancien.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.