Samba Annonce de Samba 4 Technology Preview

Posté par (page perso) . Modéré par Mouns.
Tags :
0
26
jan.
2006
Samba
Le 24 janvier est parue discrètement la première version de test de la prochaine version de Samba, 3 ans après l'ouverture de cette branche. Cette version n'est pas destinée à être utilisée en production mais est la pour permettre d'avoir des retours d'expérience ainsi que montrer la progression du projet.

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
  • # Award

    Posté par . Évalué à  10 .

    A noter que Andrew Tridgell a recu un award cette annee pour son travail dans le monde du libre.

    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 . Évalué à  9 .

      sans samba, le libre n'aurait jamais pu percer en entreprise au niveau des serveurs de fichers. Les migrations vers le libre ne pourront que se renforcer. C'est quand même magnifique tout ce boulot, on a des gens d'exception dans le libre.
    • [^] # Re: Award

      Posté par . Évalué à  -1 .

      allons bon, on retrouve tous les recompensés des FOSDEM de l'année suivante dans cet article, le winner de cette anné sera donc Andrew “Tridge” Tridgell... what a spoiler :(
  • # Samba 4 vs NFSv4

    Posté par . Évalué à  2 .

    Quels sont les avantages de Samba4 par rapport à NFSv4?
    Et ceux de NFSv4 par rapport à Samba4 ?
    • [^] # Re: Samba 4 vs NFSv4

      Posté par . Évalué à  10 .

      C'est quoi le mieux, une voiture ou un percolateur, à ton avis?

      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 (page perso) . Évalué à  4 .

        Il faut retourner à la dépêche sur NFSv4 :
        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 . Évalué à  3 .

        Je ne vois pas la situation comme ça.
        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 (page perso) . Évalué à  3 .

          • [^] # Re: Samba 4 vs NFSv4

            Posté par (page perso) . Évalué à  3 .

            ca tombe bien Microsoft gere la RFC 1001, 1002, 1510, 2251-2256
            Ils sont aussi des hommes au w3c, depuis un certain temps... certains de leurs employé ont même sortis des logiciels libres !
            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" ?

            si certains me répondent que Microsoft ne respecte pas les standards, j'aime bien lire ce texte et les auteurs
            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 (page perso) . Évalué à  -5 .

              je parle des RFC et des liens depuis le site de MS juste pour montrer de MS integre officiellement des RFC comme LDAP ou Kerberos ou SMB .

              et je cite ce document de l'équipe de SaMBa pour ce passage :
              SMB was originally carried via a proprietary network transport, the interface to which was called NetBIOS (Network Basic Input Output System). Two Internet RFCs ([RFC1001], [RFC1002]) were published which describe a mechanism for implementing the NetBIOS API on top of TCP and UDP, thus allowing SMB to be transported over IP inter-networks. Those RFCs are now known collectively as Internet Standard #19, and the transport protocol that they describe is commonly called NBT (or, sometimes, NetBT) for "NetBIOS over TCP/IP."


              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 . Évalué à  2 .

          Côté Microsoft, le boulot est (censé être) fait pour NFsv4 et l'interopérabilité se fait assez bien.
      • [^] # Et Coda ?

        Posté par . Évalué à  1 .

        A mon sens, mais peut-être que je me gourre, la principale limitation avec Samba3, c'est de ne pas pouvoir disposer d'une vraie répartition de la charge sur les serveurs. On peut faire des trucs avec openldap, DFS, mais on reste toujours tributaire du fait que le PDC est unique, et qu'un partage ne peut être réparti dynamiquement sur plusieurs serveurs.

        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 (page perso) . Évalué à  1 .

        L'avantage de Samba4, c'est donc de pouvoir remplacer un serveur Active Directory

        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 (page perso) . Évalué à  1 .

          Tu as lu la depeche avant de pondre ce commentaire?!?

          Samba 4 vise à être un équivalent parfait de active directory! (sans les bugs j'espere...)
          • [^] # Re: Samba 4 vs NFSv4

            Posté par (page perso) . Évalué à  2 .

            extrait de la dépêche :

            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 . Évalué à  1 .

              > cependant je vois pas comment Samba pourrait remplacer AD.

              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 (page perso) . Évalué à  2 .

                c'est finalement ce que je me suis dit... avec SWAT en front end ? l'avenir le dira...
                • [^] # Re: Samba 4 vs NFSv4

                  Posté par . Évalué à  1 .

                  En dehors des entreprises, je ne sais pas si ca va changer beaucoup de chose de disposer d'un joli front-end SWAT, puisque, vu que l'ancien SWAT n'était pas très "grand public", tous les éditeurs de distribution ont développé leur front-end à eux.
                  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 . Évalué à  3 .

                    A priori, le "nouveau" SWAT ne sera plus un simple outil de configuration (équivalent à l'édition directe de smb.conf, donc) mais un outil d'administration du domaine. Donc on peut espérer qu'il sera capable d'ajouter/supprimer/modifier des utilisateurs, des machines, etc.

                    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 . Évalué à  5 .

              Windows Server et Active Directory c'est tout un écosystème gèré par Microsoft et ses partenaires.
              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 . Évalué à  3 .

                - il faut gérer les sauvegardes à distances.

                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 . Évalué à  2 .

                  En théorie oui la partie serveur pourrait etre sous un autre environnement que Windows, mais en pratique ce n'est pas le cas.

                  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 . Évalué à  6 .

    Le code est plus modulaire et en grande partie auto-généré.


    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 . Évalué à  4 .

      Apparement, une grosse partie du code (celle qui concerne les appels de procédures distantes, notamment) est générée automatiquement à partir d'une définition formelle de l'interface des-dites procédures. Via ce qu'on appelle un IDL (langage de définition d'interface).

      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 (page perso) . Évalué à  4 .

      Je ne connais quasi-rien sur le sujet, mais je me permets de l'ouvrir quand même :

      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 (page perso) . Évalué à  8 .

    J'espère que l'aspect modulaire de samba4 sera mis en avant par les distribution, notament au niveau des paquets.

    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 (page perso) . Évalué à  5 .

    C'est une excellent nouvelle car jusqu'à présent, pour pouvoir intégrer des machines sous Windows à un réseau d'entreprise, soit on passe par une pièce Microsoft: Active Directory, soit on continue d'utiliser les domaines NT4 avec Samba.

    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 (page perso) . Évalué à  5 .

      Pour l'identification sous Windows, c'est pas GINA qui fait le boulot ?
      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 . Évalué à  2 .

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: Plus besoin de Microsoft en Entreprise!

          Posté par (page perso) . Évalué à  3 .

          J'avais pense a la solution pGina mais cela ne peut faire l'affaire que si l'on controle les postes clients et ce n'est, heureusement, pas la politique de la maison: chacun fait ce qu'il veut de sa machine.

          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!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.