La version 4 constitue une réécriture complète du projet, nécessaire car les versions précédentes étaient toujours basées sur le code du client Windows for Workgroups créé par Andrew Tridgell il y a plus de 10 ans et n'était ni assez modulaire ni assez souple pour suivre les évolutions de Samba.
Avec ce nouveau départ, le projet Samba vise la compatibilité totale avec Active Directory. Le protocole CIFS est en effet implémenté pour la première fois dans sa totalité. Cette pré version permet déjà de créer un Contrôleur de Domaine Active Directory et d'authentifier des clients Windows XP mais reste encore dépourvue de fonction importantes telles que le support de l'impression. Dans le but de simplifier l'administration, Samba 4 intègre ses propres serveurs LDAP et CLDAP. Ils sont utilisables via le protocole LDAP mais le backend reste le fameux LDB introduit dans Samba3. OpenLDAP reste pour autant utilisable.
La réplication WINS est maintenant fonctionnelle.
De nouveaux serveurs RPC pour Windows sont disponibles.
Le code est plus modulaire et en grande partie auto-généré.
Gensec est la nouvelle infrastructure d'authentification supportant Kerberos via l'implémentation Heimdal.
SWAT qui était anciennement une simple GUI pour éditer le fichier smb.conf est désormais repensé pour agir en vrai outils graphique d'administration.
Un module LSM pour correctement gérer la cohérence POSIX/NTFS
Aller plus loin
- Samba (12 clics)
- L'annonce (4 clics)
- PDF de la présentation SambaXP 2005 de Andrew Tridgell (8 clics)
- PDF de la thèse de Andrew Barlett pour mieux comprendre Samba4 (33 clics)
# Award
Posté par Quentin Delance . Évalué à 10.
http://www.fsf.org/news/free-software-awards-2005
Recompense meritee a mon sens car Samba est vraiment un des projets fondamentaux du libre en entreprise (cela va s'accentuer avec Samba 4).
[^] # Re: Award
Posté par dilbert . Évalué à 9.
[^] # Re: Award
Posté par roger21 . Évalué à -1.
# Samba 4 vs NFSv4
Posté par v_atekor . Évalué à 2.
Et ceux de NFSv4 par rapport à Samba4 ?
[^] # Re: Samba 4 vs NFSv4
Posté par Larry Cow . Évalué à 10.
Plus sérieusement, Samba (et particulièrement Samba4) vise plus l'intégration des technologies réseau Microsoft que le simple "partage de fichiers". NFS (v4 ou pas) est un système de fichiers "réseau", à la manière de CIFS (qui est implémenté par Samba et Microsoft, lui).
L'avantage de Samba4, c'est donc de pouvoir remplacer un serveur Active Directory par du libre (et du Unix, aussi). Donc arrêter d'avoir une pièce maîtresse de l'informatique d'entreprise coincée sous Windows.
L'autre avantage, c'est que ça permet de dialoguer avec le monde Windows (échanger des fichiers, par exemple), ce qu'NFS ne permet pas simplement.
L'avantage de NFS, à part être mieux intégré à Unix (et encore), je ne vois pas trop. Mais si quelqu'un peut m'éclairer j'en serais ravi :)
[^] # Re: Samba 4 vs NFSv4
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
http://linuxfr.org/2006/01/14/20214.html
voici par exemple un commentaire intéressant
http://linuxfr.org/comments/671238.html#671238
[^] # Re: Samba 4 vs NFSv4
Posté par ookaze . Évalué à 3.
NFS peut parfaitement permettre à un Windows d'échanger des fichiers avec Windows, tout comme Windows permet d'utiliser tout un tas de moyens d'authentification autres que AD et cie.
De la façon dont je le vois, avec Samba, le boulot est du côté du Libre, et on peut compter sur l'envie général d'être interopérable et de produire de bons outils de ce côté.
Pour NFSv4 (ou d'autres protocoles comme LDAP, Kerberos, Coda, ...), ce serait à MS de faire le boulot, et on ne peut pas du tout compter sur eux pour faire quelque chose d'interopérable ou faire un bon boulot.
Je ne dis pas ça gratuitement, je me base simplement sur ce qu'ils ont produit jusqu'à présent dans le domaine : SFU, AD, CIFS entre autres.
[^] # Re: Samba 4 vs NFSv4
Posté par Mouns (site web personnel) . Évalué à 3.
http://www.faqs.org/rfcs/rfc1001.html
http://www.faqs.org/rfcs/rfc1002.html
http://www.faqs.org/rfcs/rfc1510.html
http://www.faqs.org/rfcs/rfc2251.html
http://www.microsoft.com/technet/prodtechnol/windows2000serv(...)
http://support.microsoft.com/kb/q119493/
http://support.microsoft.com/default.aspx?scid=kb;en-us;3210(...)
http://www.microsoft.com/windowsserver2003/techinfo/overview(...)
et si certains me répondent que Microsoft ne respecte pas les standards, j'aime bien lire ce texte et les auteurs : http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-1(...)
[^] # Re: Samba 4 vs NFSv4
Posté par un_brice (site web personnel) . Évalué à 3.
De là à extrapoller des choses sur la stratégie de l'entreprise... d'ailleurs, ces 5 documents ont l'air de datter de 1987 pour le premier et 1997 pour le derniers, et le nom de microsoft n'y figure pas. Tu voulais dire quoi par "gérer" ?
C'est à dire un document de 23 pages, décrivant la manière d'écrire des URIs pour les ressources accessibles par SMB.
Et donc tu le lit à chaque fois que quelqu'un repproche à microsoft de ne pas respecter les standards ? Ça te laisse le temps de vivre ?
En plus je vois mal dans quel but : le fait que ce soient les gars de Samba qui aient dû inventer la manière de donner une URI aux ressources accessible par SMB me parrait au contraire démontrer que les gars de microsoft n'avaient pas du tout pris en compte ce problème.
[^] # Re: Samba 4 vs NFSv4
Posté par Mouns (site web personnel) . Évalué à -5.
et je cite ce document de l'équipe de SaMBa pour ce passage :
pour ce qui est de la prise en compte des problemes, je tiens à te rappeler que MS n'est en aucun cas responsable de la nom prise en compte de plein de choses dans des protocoles comme SMTP ou SNMP ou HTTP ou DNS. Mais bon, je suis sur que tu ne vois pas de quoi je parle et que tout ce qui sort de chez MS est pour toi necessairement de la merde.
[^] # Re: Samba 4 vs NFSv4
Posté par v_atekor . Évalué à 2.
[^] # Et Coda ?
Posté par denisb . Évalué à 1.
NFSV4 répond en partie à ces objectifs, mais il ne faut pas se leurrer, avec des clients M$, cela ne fonctionnera pas...
Coda est super intéressant, mais de l'aveu même des développeurs, c'est du beta pour windows, et encore avec des fonctionnalités limitées...
Pourtant le principe suivant : pouvoir utiliser la capacité de stockage des postes clients pour faire un espace de stockage unique, redondant , tolérant aux pannes et problèmes réseau et adaptatif doit bien concerner disons 80% des cas des parcs M$ avec des serveurs Samba.
Etrange que ce besoin n'ait jamais été vraiment pris en compte !
A moins que justement samba4 aille dans ce sens ?
[^] # Re: Samba 4 vs NFSv4
Posté par j (site web personnel) . Évalué à 1.
remplacer un controleur de domaine/serveur de fichiers, ok, mais ce n'est pas le role de Samba de remplacer Active Directory (sauf erreur de ma part)
[^] # Re: Samba 4 vs NFSv4
Posté par gnumdk (site web personnel) . Évalué à 1.
Samba 4 vise à être un équivalent parfait de active directory! (sans les bugs j'espere...)
[^] # Re: Samba 4 vs NFSv4
Posté par j (site web personnel) . Évalué à 2.
Avec ce nouveau départ, le projet Samba vise la compatibilité totale avec Active Directory
j'ai déjà utilisé samba en tant que controleur de domaine et serveur de fichiers mais AD je connais très mal.... cependant je vois pas comment Samba pourrait remplacer AD.
[^] # Re: Samba 4 vs NFSv4
Posté par mcben . Évalué à 1.
En intégrant un serveur de type LDAP.
Il servira, je suppose, à stocker les informations sur les utilisateurs, les groupes, les machines, les imprimantes et pleins d'autres choses.
[^] # Re: Samba 4 vs NFSv4
Posté par j (site web personnel) . Évalué à 2.
[^] # Re: Samba 4 vs NFSv4
Posté par Pol' uX (site web personnel) . Évalué à 1.
Je pense que, mis à part (je répete ...) pour un usage complexe (et encore, je préfère largement smb.conf) SWAT (joli ou pas) ne servira qu'a très peu de gens.
Adhérer à l'April, ça vous tente ?
[^] # Re: Samba 4 vs NFSv4
Posté par Larry Cow . Évalué à 3.
En gros, exactement ce qui plait aux administrateurs Microsoft dans AD (l'interface graphique) mais en version web.
[^] # Re: Samba 4 vs NFSv4
Posté par koopa . Évalué à 5.
Il n'y a pas que l'authentification, le partage des fichiers et le serveurs d'impression. Il y a aussi:
- les politiques de groupe
- la délégation fine des pouvoirs via les MMC (Microsoft Management Console) (par exemple autoriser les chefs de services à réinitialiser les mots de passes de leurs employés sans pour autant avoir le droit d'effacer, renommer, créer des comptes)
- l'installation automatique des logiciels sur les postes clients via les fichiers MSI
Samba c'est génial, mais les serveurs Microsoft reste indispensables dès que un as un certain nombre de machines Windows clientes
ex:
- il faut un serveur WSUS pour distribuer les maj de sécurité de windows
- il faut une solution centralisée pour gérer la mise à jour et le paramétrage des antivirus/antispyware
- il faut gérer les sauvegardes à distances.
Le problème avec Microsoft, c'est que tu es très vite pris dans l'engrenage: une fois que tu utilises Active Directory, tu te rends compte que tu as besoin de plein d'autres
logiciels Microsoft ou de ses fidèles partenaires.
[^] # Re: Samba 4 vs NFSv4
Posté par Prosper . Évalué à 3.
Je vois pas en quoi les sauvegardes seraient tributaire d'un environnement windows, à part le client/agent que tu mets sur le poste client , la partie serveur de ta sauvegarde peut très bien être sous un autre environnement que windows.
[^] # Re: Samba 4 vs NFSv4
Posté par koopa . Évalué à 2.
Pourtant il y avait le logiciel backuppc http://backuppc.sourceforge.net/ mais comme il ne gère pas les ACLs ni les fichiers verrouillés, et bien le logiciel n'est pas utilisable pour sauvegarder un serveur Windows.
# auto-généré
Posté par Rémi baudruche . Évalué à 6.
Ca veux dire quoi ?
qu'il a été généré automatiquement à partir de windows ?
non, plus serieusement, je suis curieux de savoir.
[^] # Re: auto-généré
Posté par Larry Cow . Évalué à 4.
Après, il y a peut-être d'autres endroits où le code est "généré", mais celui-ci semble évident.
[^] # Re: auto-généré
Posté par ナイコ (site web personnel) . Évalué à 4.
Samba4 utilise (je crois) IDL : Le principe est de décrire ce que tu veux obtenir, par exemple un bout de code qui traite tel type de paquet de tel protocole, et pof!, le code se génère tout seul. Bon, mon explication seuxe; voici de la matière, par le maître himself:
http://lists.samba.org/archive/samba-technical/2005-January/(...)
Et : http://www.google.fr/search?q=idl+auto+generated+code&st(...)
Enfin, je crois que bientôt il va y avoir un VServer de plus au boulôt... Ou alors sur mon portable, comme ça on pourra faire une Samba4 party la semaine prochaine a SL2006 ;-)
# modularité
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
C'est très bien un samba qui peut parfaitement remplacer AD, être un serveur d'impression et tout et tout.
En pratique, j'aimerais bien que mon serveur de fichier samba n'ai pas le code d'AD, ni tout le code correspondant au serveur LDAP, ni la partie impression... De même pour mon serveur d'impression. Pour mon controleur de domaine, je vire la partie impression et partage de fichiers. Plus le code est réduit, moins il y a d'erreur et de risque de se faire pirater.
En effet, ne faisons pas la même erreur que windows à tout mettre dans le même panier.
Bref, tout plein de petit paquets bien sympathique à installer ;-)
# Plus besoin de Microsoft en Entreprise!
Posté par k. stephane . Évalué à 5.
L'utilisation de Samba 3 n'est pas optimale car on n'a pas accès au "Single Sign On" qui a été introduit par Microsoft avec l'utilisation de Kerberos par Windows 2000 Active Directory. L'utilisateur doit cacher ses mots de passe ou les re-taper.
Et non, il n'y a pas plusieurs façons de s'authentifier sous Windows, soit on a les utilisateurs listés en local, soit on fait partie d'un "domaine" Windows (soit on utilise une solution propriétaire bien chère). Le local, quand on a plusieurs milliers d'utilisateurs, c'est impensable. Et unse solution propriétaire, c'est se lier les mains.
Chez nous (plus de 6000 utilisateurs), on est en tout Unix (Linux et Solaris) pour les serveurs et on ne veut pas de Microsoft, résultat, on est obligés de rester en NT4 avec tout les problèmes que cela implique. On voulait passer à Kerberos pour avoir le Single Sign On et la seule solution, c'est de mettre un serveur AD dans notre parc. Pas bon ça. Par principe, dans les faits, ce serveur ne serait qu'une copie de notre Fedora Directory LDAP et l'authentification se ferait par un Kerberos KDC MIT.
Tout cela aurait été plus simple si MS avait implémenté Kerberos à la lettre (sans ajouter ses petites features non-documentées) et si le schéma et le protocole LDAP de AD était public...
Cette nouvelle version de Samba va régler mes problèmes de conscience! En plus d'ajouter de la sécurité à notre réseau.
[^] # Re: Plus besoin de Microsoft en Entreprise!
Posté par inico (site web personnel) . Évalué à 5.
Et des remplacement pour GINA, je trouve en plus des solutions proprietaire novell ceci:
http://pgina.xpasystems.com/
Pgina propose un systéme de plugin tels que:
Slashdot ( http://pgina.xpasystems.com/?page_id=11 )
PAM ( http://pgina.xpasystems.com/?page_id=8 )
LDAP ( http://pgina.xpasystems.com/?page_id=6 )
C'est opensource aussi.
Bon test ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Plus besoin de Microsoft en Entreprise!
Posté par k. stephane . Évalué à 3.
pGina ne comporte pas d'aurtes avantages sur une solution winlogon NT4 basee sur Samba que la customisation. Nous avons trouve cela inutile, puisqu'il nous est plus facile de travailler cote serveur, scripts, backend LDAP...
De plus pGina ne supporte pas (officiellement) Kerberos donc franchement je n'en vois pas l'utilite car si on a du Windows dans son organisation on a forcement un serveur Samba pour les fichiers et l'impression. Ce serveur peut aussi fonctionner comme un serveur d'authentification donc meme resultat avec moins de boulot et pas de changement cote client.
L'avantage de AD sur NT4 c'est l'implementation de Kerberos, c'est ca qui est important. Et Samba 4 implemente cela. Donc encore une fois: pas de changement cote client et administration serveur facile pour des unixiens.
Il existe bien Kerberos for Windows du MIT mais les applications Microsoft (dont IE et Outlook) ne permettent pas d'utiliser une autre bibliotheque kerberos que celle du systeme. Ca marche avec Eudora et Firefox mais comment dire a notre departement cravattes costumes de finances qu'on ne supporte pas Outlook?
Dans mon equipe on fait comme ca et on n'a meme pas un admin Windows!
[^] # Re: Plus besoin de Microsoft en Entreprise!
Posté par tipi (site web personnel) . Évalué à 2.
voir :
http://www.ads-lu.com/produits/serveur.php
http://wawadeb.crdp.ac-caen.fr/iso/tmp/ressources/ldap/Etude(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.