Sortie de Samba 4 alpha 11

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
24
16
jan.
2010
Samba
Samba4 alpha11 est sortie, il y a quelques jours de cela. Soit près de deux ans et demi après l'annonce sur LinuxFR de la sortie de l'alpha1.
La version 4 de Samba vise à offrir une alternative libre et compatible au service d'active directory de Microsoft, présent dans toutes les versions serveurs du système d'exploitation Windows depuis la version Windows 2000. Outre la partie active directory, Samba 4 continuera d'offrir une implémentation libre du service de partage de fichiers et impression.

Depuis quelque temps maintenant, Samba4 est capable de se comporter comme un contrôleur de domaine active directory pour la plupart des tâches courantes. Dernièrement la version alpha9 a vu l'arrivée de la gestion des droits d'accès (ACL) au niveau des objets de l'annuaire et la réplication entre les contrôleurs de domaine (protocole DRS).

Cette onzième itération d'alpha améliore grandement la gestion de ce protocole puisque Samba 4 peut maintenant joindre un domaine avec un autre contrôleur Samba, mais aussi un domaine avec contrôleur Microsoft Windows (jusqu'à la version 2008 server R2). On peut aussi ajouter un serveur Microsoft Windows à un domaine avec un (ou plusieurs) contrôleur(s) Samba et même le promouvoir contrôleur.

La gestion de la réplication entre contrôleurs de domaine est importante car elle permet de ne plus avoir un point de faiblesse unique (SPOF) et pourrait marquer le départ d'une utilisation plus importante de Samba4. Il est à noter que malgré son statut alpha, il existe quelques entreprises qui l'utilisent quotidiennement et que quelques autres pensent à l'utiliser.

L'équipe samba invite toutes les personnes désireuses de tester cette nouvelle version à le faire et, pourquoi pas, à contribuer au code du logiciel.

Aller plus loin

  • # Précisions

    Posté par  . Évalué à 5.

    Même si le fait de poser la question signifie que ça ne me servira à rien. Qu'est-ce que l'active directory? À quoi ça sert? Pourquoi est-ce si utile? Y-a-t'il des alternatives libre (c'est-à-dire pas basé sur le protocole de MS mais qui remplissent les mêmes fonctions)?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Précisions

      Posté par  . Évalué à 3.

      Et tant que j'y suis. Il y a une date (pas trop large) de prévue pour la sortie de la finale?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Précisions

      Posté par  (Mastodon) . Évalué à 2.

      Oui, oui... si quelqu'un peut nous éclairer sur AD... pour, c'est plus ou moins un annuaire LDAP (oui, non ? conforme à la norme "étendu" à la mode MS), plus ... je ne sais pas quoi (un truc genre kerberos ??)
      Quelqu'un a des lumières ?
    • [^] # Re: Précisions

      Posté par  . Évalué à 8.

      AD c'est un annuaire pour les reseaux de PC sous windows.
      On peut y stocker les informations des comptes mais aussi des groupes, des machines, des imprimantes, la conf des serveurs DNS dont il est tres dependant, et pleins d'autres trucs (info exchange, etc).
      Il peut etre repliqué sur plusieurs serveurs assez facilement en integrant des systemes de deleguation de l'administration.

      Mais y'a pas que ca non plus, y'a un systeme de GPO qui permet de deployer des configurations systemes sur les stations (mais c'est limité aux confs pour les outils MS, le reste est ignoré complet)
      On peut deployer les montages de partages reseau et les imprimantes.
      Y'a aussi un systeme de deploiement d'applis mais c'est une daube complete.


      Actuellement, sans AD, un parc de plus de 10 ou 12 machines sous windows est quasi ingerable.

      Sous linux, il manque cruellement d'un mecanisme a peu pres equivalent. Attention ! faut surtout pas reproduire ce bousin ! mais en reprendre ce qui est pas mal : deploiement de conf facile, centralisation de l'auth, des machines, etc.
      Je pense que ca doit pas etre tres complique car beaucoup de briques existent deja (ssh, repository, packages, etc) et on pourrait faire bien mieux.
      Tout le probleme est qu'il n'y a rien d'unifié et user-friendly.
      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 4.

        > Sous linux, il manque cruellement d'un mecanisme a peu pres equivalent

        Effectivement, tu peux pas faire du tout en un mais avec OpenLDAP en centralisation et puppet en gestion des configurations et scripts, tu peux faire quelque chose de propre et qui tourne bien (et qui marche aussi sous *BSD et Solaris, ce qui est un autre avantage pour mon parc).

      • [^] # Re: Précisions

        Posté par  . Évalué à 7.

        Actuellement, sans AD, un parc de plus de 10 ou 12 machines sous windows est quasi ingerable.
        J'ai l'air con avec mes 300 machines Windows (dont environ 45 serveurs) réparties sur 36 sites, le tout sans Active Directory (qui est une bouse sans nom, c'est clair) :-)
        • [^] # Re: Précisions

          Posté par  (site web personnel) . Évalué à 7.

          Moi, j'ai 150 machines sans AD et mes machines n'ont pas le partage de réseau d'activé (donc pas de psexec) et cela marche plutôt bien ;-)

          Ce qu'il manque à Windows, c'est un serveur SSH de base et une vraie ligne de commande pour pouvoir scripter et libérer les possibilités de l'administrateur système.

          J'ai autant de machine GNU/Linux et je ne veux surtout pas ce clickodrome AD pour les gérer. J'ai quelques dizaines de fichiers cfengine versionnés avec subversion qui m'explique pour qui sait lire tout cela très bien. Et en plus, dans 1Mo, j'ai 5 ans de config pas à pas !

          Bref, l'AD est à mon sens une mauvaise réponse à un vrai problème.
          • [^] # Re: Précisions

            Posté par  . Évalué à 0.

            je ne veux surtout pas ce clickodrome AD pour les gérer

            Personne ne t'oblige a utiliser une UI pour gerer AD tu sais.

            Niveau scripting, t'as powershell que tu peux installer sur toutes les machines depuis XP.
            • [^] # Re: Précisions

              Posté par  (site web personnel) . Évalué à 2.

              PowerShell ne tourne pas sous 2000... de plus, il n'est pas installé par défaut sur les postes. Cela signifie qu'il faut déjà une procédure spéciale pour installer un langage de script correct. Dans ce cas là, je préfère autant installer Perl ;-)
              • [^] # Re: Précisions

                Posté par  . Évalué à 4.

                il n'est pas installé par défaut
                Mouais, ce n'est pas franchement un argument recevable :-)
                Avec Debian, le serveur ssh n'est pas installé par défaut. Ni Perl.
                • [^] # Re: Précisions

                  Posté par  (site web personnel) . Évalué à 1.

                  On m'a dis (un installateur de Windows 2008 core, j'ai pas testé) que les différentes versions du PowerShell n'était pas compatible entre elle et qu'un vbscript était plus pérenne.

                  Debian (dans sa version minimale) certes n'installe pas ssh mais perl est dedans à ma connaissance (je l'ai toujours et ne l'ai jamais installé). Certes, il faut mettre ssh ce qui se résume à tapper 20 caractères sur son clavier, cela doit être l'affaire de quelques secondes.

                  Si tu installes Windows 2008 core, tu n'as pas PowerShell (je crois me souvenir) et la, tu pleures pour l'installer...

                  Sinon, pour en revenir au sujet que tu évoques, pourquoi le PowerShell n'est pas installé par défaut ? Cela montre à mon sens que Microsoft ne pousse pas cette technologie. D'ailleurs aucun des informaticiens autour de moi pro-Windows ne fait de script powershell. J'en ai même un qui fait tout en Perl...

                  Debian fait beaucoup d'effort pour virer Perl du système de base, non pas parce Perl c'est pas bien mais pour avoir un système minimal le plus petit possible avec l'embarqué pour objectif. L'idée est d'avoir la même base pour les gros et les petits systèmes.

                  Mais avec le jeu des dépendances (gérées), Perl, Python... arrivent tout seul rapidement sur un poste de travail.
                  • [^] # Re: Précisions

                    Posté par  . Évalué à 2.

                    sOn m'a dis (un installateur de Windows 2008 core, j'ai pas testé) que les différentes versions du PowerShell n'était pas compatible entre elle et qu'un vbscript était plus pérenne.

                    C'est faux, cf. http://blogs.msdn.com/powershell/archive/2009/05/06/powershe(...)

                    Debian (dans sa version minimale) certes n'installe pas ssh mais perl est dedans à ma connaissance (je l'ai toujours et ne l'ai jamais installé). Certes, il faut mettre ssh ce qui se résume à tapper 20 caractères sur son clavier, cela doit être l'affaire de quelques secondes.

                    Si tu installes Windows 2008 core, tu n'as pas PowerShell (je crois me souvenir) et la, tu pleures pour l'installer...


                    Tout a fait oui, c'etait a mon avis un choix stupide de MS

                    Sinon, pour en revenir au sujet que tu évoques, pourquoi le PowerShell n'est pas installé par défaut ? Cela montre à mon sens que Microsoft ne pousse pas cette technologie. D'ailleurs aucun des informaticiens autour de moi pro-Windows ne fait de script powershell. J'en ai même un qui fait tout en Perl...

                    Depuis 2008 R2 il est installe par defaut, il ne l'etait pas avant car il a ete considere qu'il n'y avait pas assez de temps pour integrer powershell de maniere stable et acceptable au systeme au moment de Vista/WS08, donc il est sorti de maniere separee.
                    Maintenant je vois ca comme un detail, si tu installes un ou deux systemes, ca prend 2 minutes de plus de le faire, si tu installes des tas de systemes, normalement tu as une image, et la tu mets powershell dedans et c'est regle.
                    • [^] # Re: Précisions

                      Posté par  (site web personnel) . Évalué à 2.

                      Je travaille sans image car dans la recherche, on achète les PC au fur et à mesure et que du sur mesure. Bref, très peu de PC absolument identique. J'ai bien travaillé sur une procédure d'installation automatique pour mon laboratoire mais celui-ci est trop petit (350 PC) pour maintenir ce genre d'infrastructure (il faut dire que c'est <> de faire un CD d'XP qui marche sur pas mal de matériel et qui s'installe sans poser de question).

                      En plus, le CNRS a basculé sur HP donc maintenant on est sur deux marques...

                      Bref, j'ai regardé le temps mis à faire click click et le temps mis à maintenir mes installations automatique et je suis retourné au click clik un peu désabusé.
                      • [^] # Re: Précisions

                        Posté par  (site web personnel) . Évalué à 1.

                        Damned, j'avais un "chiant" entre deux crochets inférieur et supérieur et celui-ci est partis ! dlfp tournerait-il sous IIS ;-)
          • [^] # Re: Précisions

            Posté par  . Évalué à 4.

            Un serveur SSH (basé sur OpenSSH+cygwin) qui s'installe en quelques instants et qui donne accès à une vraie ligne de commande sous Windows :
            https://pulse2.mandriva.org/wiki/SSHAgentNews
            • [^] # Re: Précisions

              Posté par  (site web personnel) . Évalué à 2.

              Je connaissais CopSSH qui est très bien maintenu depuis des années. Celui-ci a une qualité rare, il est très clair sur les versions des composants utilisés ainsi que sur les licences.

              http://www.itefix.no/i2/copssh

              Le paquetage Mandriva a l'air moins clair au premier abord. Après, je n'ai pas été plus loin et comparé les deux environnement.
          • [^] # Re: Précisions

            Posté par  . Évalué à 1.

            Petites question bêtes vu que je suis aussi dans le même cas mais avec AD, comment faites vous pour gérer vos utilisateurs par machines ?
          • [^] # Re: Précisions

            Posté par  (site web personnel) . Évalué à -1.

            Bah y a quand même les GPO qui sont pratiques pour éviter que nos amis les utilisateurs fassent n'importe quoi avec leur environnement de travail (genre, pas le droit d'outrepasser le proxy antiviral de la boîte dans IE)...

            Sous Linux, le concept me paraît plus difficile à reproduire : certes, je peux déployer des fichiers de conf' globaux dans /etc avec cfengine/puppet/etc., mais ça n'empêchera pas l'utilisateur de les outrepasser en rajoutant un fichier de conf' dans son répertoire personnel. Et là, à part créer moi-même des fichiers de conf' vides et lui enlever les droits d'écriture dessus, il n'y a guère de solutions (et je ne parle même pas des applis qui acceptent un fichier de conf' différent en changeant la ligne de commande). C'est un peu dommage, parce que je connais des admins qui seraient très frileux à déployer un système où ils ne seraient pas certains d'avoir le contrôle sur les postes utilisateurs.

            Envoyé depuis mon PDP 11/70

            • [^] # Re: Précisions

              Posté par  (site web personnel) . Évalué à 3.

              Pour éviter que nos amis les utilisateurs fassent n'importe quoi avec leur environnement de travail (genre, pas le droit d'outrepasser le proxy antiviral de la boîte dans IE)

              alors qu'il suffit aux utilisateurs d'installer un vrai navigateur web, respectueux des standards, tel FireFox, plutôt que d'utiliser cette bouse trouée par conception qu'est IE... et hop ils peuvent utiliser un autre proxy :)
              • [^] # Re: Précisions

                Posté par  . Évalué à 5.

                d'autant plus vrai actuellement au regard du CERT etc...
              • [^] # Re: Précisions

                Posté par  (site web personnel) . Évalué à 0.

                alors qu'il suffit aux utilisateurs d'installer un vrai navigateur web, respectueux des standards, tel FireFox, plutôt que d'utiliser cette bouse trouée par conception qu'est IE... et hop ils peuvent utiliser un autre proxy :)
                Euh, oui... Mais c'est justement ce qu'on ne veut pas : que tout le monde installe des applis non autorisées, utilise un proxy non contrôlé par la boîte (bon, là, le pare-feu fait l'affaire), etc. Et, je le redis, c'est là que les GPO sont une bonne chose : en quelques coups de cliquodrome, l'environnement utilisateur devient prévisible. Pour l'admin (moi, par exemple ;-), c'est très reposant. D'où ma déception de ne pas avoir un outil semblable sous Linux...

                Envoyé depuis mon PDP 11/70

                • [^] # Re: Précisions

                  Posté par  (site web personnel) . Évalué à 3.

                  mais les GPO n'empêchent à l'utilisateur d'installer une alternative ;-) elles sont par conception contournables, faire reposer la sécurité dessus c'est àmha sous-estimer les capacités de contournement des utilisateurs (d'autant lorsqu'on leur met des bâtons dans les roues ou, en tout cas, ce qu'ils perçoivent ainsi). Combien de fois j'ai eu la remarque "avec IE, il faut à chaque fois retaper son mot de passe proxy" et la réponse qui fuse à côté "installe Firefox, il peut le retenir pour toi".

                  ça me rappelle les admins paranos que j'ai pu rencontrer (parano au sens tout ce qui n'est pas autorisé est interdit) alors qu'avec les admins prudents (tout est autorisé sauf ce qui est interdit) ça allait un peu mieux, ou permettait de comprendre les limitations.
                  Avec les admins laxistes (ceux qui sont soit incompétent, soit s'en foutent ou n'ont pas pensé à tout), j'ai eu autant de soucis que les paranos, alors qu'avec les prudents, il est possible de demander à lever des interdits (avec une bonne justification).
                  Bon je n'ai pas retrouvé cette classification que j'avais lue au siècle dernier... J'ai retrouvé [1] et [2] qui sont un peu agressifs au 1er degré et clairement à prendre au 2ème degré (un peu comme [3] que je relis régulièrement).

                  Puis, bon, l'utilisateur a un accès physique à son poste de bureau, autant prendre son parti qu'il est administrateur de son poste... et gérer avec les outils de diagnostic habituels.

                  [1] http://www.etoyoc.com/home/45 sysadmin personality types
                  [2] http://www.gnu.org/fun/jokes/know.your.sysadmin.html (ya fun et jokes tout de même :p)
                  [3] http://www.gnurou.org/writing/smartquestionsfr qui me rappelle que les utilisateurs ne savent pas toujours poser leur question (et n'ont pas lu cette url /o\)
      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 3.

        Sous linux, il manque cruellement d'un mécanisme à peu près équivalent.

        o_O
        Red Hat a des travaux sur le sujet...
        Mandriva Linux intègre Mandriva Directory Server[1] (disponible en plus avec bacula, pour les sauvegardes, sur la version corporate : Mandriva Enterprise Server 5 aka MES5) et disponible de base en libre aussi[2]

        Pour la gestion de déploiements (des Unix, des windows, des Linux et même de MacOSX...), il y a aussi Pulse2 : http://pulse2.mandriva.org/

        [1] http://mds.mandriva.org/ et http://wiki.mandriva.com/fr/Mandriva_Directory_Server (avec copies d'écran, dispo en clickodrome et en ligne de commande) qui intègre un OpenLDAP et tout ce qui va autour

        [2] http://sophie.zarb.org/rpm/2010.0,/mmc-web-base (par exemple) et autres paquets disponibles en libre, et pour Debian GNU/Linux aussi d'ailleurs (dépôts apt dispos)
      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 2.

        deploiement de conf facile

        SCP ou SFTP avec clefs SSH. Ou carrément montage réseau de /etc.

        centralisation de l'auth

        LDAP

        des machines

        Pas compris.
      • [^] # Re: Précisions

        Posté par  . Évalué à 1.

        """
        Sous linux, il manque cruellement d'un mecanisme a peu pres equivalent. Attention ! faut surtout pas reproduire ce bousin ! mais en reprendre ce qui est pas mal : deploiement de conf facile, centralisation de l'auth, des machines, etc.
        """

        Bonjour,
        la solution se profile tout de même à l'horizon : http://freeipa.org/page/Main_Page
  • # Licences CAL ?

    Posté par  . Évalué à 4.

    Une question qui me vient, c'est que deviennent les conditions d'achat des CAL (Client Access Licenses) si tous les DC, les serveurs de fichiers, et d'impression deviennent des Samba4, mais que quelques serveurs Windows sont conservés (MSSQL par ex.) ?
    La doc est ici " http://www.microsoft.com/france/serveur/windowsserver/licenc(...) " : peut on en déduire que les 20€ (il me semble) par "client" peuvent être oubliés ? Pas négligeable quand on hésite à remplacer les serveurs 2000/2003 par du 2008 par ex. et qu'on est contraint d'"upgrader" les CAL...

    Je pensais aussi que les GPO ne seraient jamais implémentées dans SAMBA, mais je viens de lire ceci : http://wiki.samba.org/index.php/Samba4/HOWTO#Implementing_Gr(...)
    Ça devient donc vraiment très intéressant pour un environnement full MS, espérons quand même qu'il ne faudra pas deux ans de plus avant la version finale, quand bien même l'alpha serait déjà assez stable...
    • [^] # Re: Licences CAL ?

      Posté par  . Évalué à -1.

      Moi, je croyais meme que ce projet etait en train de mourir...

      Visiblement, c'est pas le cas et c'est une excellente nouvelle ! \o/
      Et les nouveautés ont l'air geniales. Vivement qu'on puisse se debarraser de Samba3 qui se fait vieillissant...
      • [^] # Re: Licences CAL ?

        Posté par  (site web personnel) . Évalué à 2.

        >Moi, je croyais meme que ce projet etait en train de mourir...
        Oulla non ! Actuellement il y a un regain d'activité sur la partie Samba4 avec pas mal de nouvelles personnes aussi bien payé par des boites (ie. cisco, sernet) que sur leur temps libre.

        >Visiblement, c'est pas le cas et c'est une excellente nouvelle ! \o/
        >Et les nouveautés ont l'air geniales. Vivement qu'on puisse se debarraser de Samba3 qui se fait >vieillissant...
        En fait Samba 3 n'est pas très vieillisant, il est même assez à jour (ie. support du protocole smb2) super support de la partie serveur d'impression, plus plein d'autres appels RPC comme la possiblité de faire joindre une machine A via un samba 3 au domaine (remote net join en anglais dans le texte). C'est donc un logiciel où les évolutions continuent mais contrairement à samba 4 c'est plus par petite touches.
    • [^] # Re: Licences CAL ?

      Posté par  . Évalué à 1.

      Tu es encore dépendant des cal à cause d'exchange.
      • [^] # Re: Licences CAL ?

        Posté par  . Évalué à 0.

        Hmmm, de notre côté on est sous Domino...
        Restent pas mal de Windows :
        - une appli sous Oracle avec des process locaux et des clients qui s'authentifient sur la base Oracle : a priori exclu de la CAL Win ?
        - une appli web sous IIS avec une base SQL : exclu de la CAL
        - un serveur windows update (WSUS) : aucune idée...
        - ...
        Je suis certain qu'un commercial Microsoft me trouvera - quoi qu'il en soit - une bonne raison de repayer des CAL ! (par solidarité avec la branche Microsoft Haïti ?...)
      • [^] # Re: Licences CAL ?

        Posté par  (site web personnel) . Évalué à 1.

        Il ne faut pas confondre les CAL au niveau du domaine qui coûtent ~15/20 euro et les CAL exchange qui coûtent bien plus (30/60 ou même 90euro).

        A propos d'exchange il y a le projet openchange (http://www.openchange.org/) qui vient justement de faire une release 0.9, la partie serveur est encore jeune mais cela reste un projet prometeur.
  • # Reste plus qu'à :-)

    Posté par  . Évalué à 3.

    Je sens qu'il va me falloir tester cette nouvelle mouture. Non pas pour Active Directory, mais plutôt pour savoir si l'utilisation "entreprise" est envisageable. Parmis les défauts de Samba 3, il y a entre autres le non héritage des permissions. C'est très très très problématique. Il y a également le fait qu'on ne peut changer les permissions qu'avec des manoeuvres spécifiques (au lieu d'un clic droit, menu propriétés, onglet sécurité).

    La documentation de la version 3 est claire: il n'est pas question de s'occuper de cela à l'avenir.
    • [^] # Re: Reste plus qu'à :-)

      Posté par  (site web personnel) . Évalué à 4.

      >La documentation de la version 3 est claire: il n'est pas question de s'occuper de cela à l'avenir.
      La documentation ne doit pas être totalement à jour car c'est pas (plus ?) vraiment le cas pour un système qui supporte les ACL posix, il y a un mapping qui est fait entre les ACL NT et posix et comme les ACL posix supportent l'héritage (enfin plus ou moins) ça marche.

      Pour un mapping parfais il faut utiliser le module acl_xattr (qui a été développé l'an dernier, cf. la présentation de jeremy allison [http://www.sambaxp.org/files/SambaXP2009-DATA/Jeremy_Allison.odp]) via
      vfs objects = acl_xattr
      dans son smb.conf
  • # Un peu de mal

    Posté par  . Évalué à 1.

    J'ai un peu du mal à comprendre samba c'est aussi ce qui permet par exemple de faire du partage de document en réseau, j'avais crus voir que maintenant le noyau intègre directement certaines fonctionnalités avec CIFS.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un peu de mal

      Posté par  (site web personnel) . Évalué à 3.

      > l'avais crus voir que maintenant le noyau intègre directement certaines fonctionnalités avec CIFS.


      C'est la partie "cliente" pas la partie "serveur" qu'il y a dans le noyau.
    • [^] # Re: Un peu de mal

      Posté par  (site web personnel) . Évalué à 1.

      Comme indiqué dans un autre commentaire, c'est la partie client CIFS qui est dans le noyau. De plus comme indiqué dans la dépêche, Samba ne fait pas que de fournir un serveur de fichier il implémente en plus un tas de RPC utilisés par les machines windows

Suivre le flux des commentaires

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