Sortie de Samba 4.16.x

Posté par  . Édité par Benoît Sibaud, Xavier Teyssier et palm123. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
36
13
juin
2022
Samba

Samba n'a plus été évoqué sur LinuxFr.org depuis un certain temps. Cela reste pourtant une brique importante fournissant une excellente alternative à l'Active Directory de Microsoft.

Pour mémoire, Samba est la suite standard de programmes d'interopérabilité Windows pour Linux et Unix. Logiciel libre sous licence GPL, le projet Samba est membre de la Software Freedom Conservancy. Depuis 1992, Samba fournit des services de fichiers et d'impression sécurisés, stables et rapides pour tous les clients utilisant le protocole SMB/CIFS. Samba est un composant important pour intégrer de manière transparente les serveurs et ordinateurs de bureau Linux/Unix dans les environnements Active Directory. Il peut fonctionner à la fois comme contrôleur de domaine et comme membre ordinaire du domaine.

Les versions correctives 4.16.1 et 4.16.2 ont été publiées le 2 mai et le 13 juin. La branche 4.16, datant du mois de mars 2022 apportait entre autres nouveautés une implémentation complète d'un contrôleur de domaine et d'un service Active Directory compatible avec l'implémentation de Windows 2008 et pouvant servir toutes les versions des clients Windows pris en charge par Microsoft, y compris Windows onze. Elle considère aussi le vénérable protocole SMB1 comme obsolète et le désactive par défaut.

Aller plus loin

  • # Toujours le souci des débits...

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

    Intéressant, merci pour la news…

    Reste qu'en accès distant, j'ai des débits misérables via SMB, hélas… :-(

    La différence est flagrante entre une copie du fichier par téléchargement via serveur apache, et une simple copie via Samba. Alors que la ligne est capable de taper plus de 300Mb/s en upload, le débit fluctue autour de la moitié via Samba, voir bien pire.

    Même sur un réseau Ethernet, ce n'est pas frapadingue, NFS, SSHFS, et iSCSI font tous preuve d'une plus grande rapidité d'échange de données à côté, mais sont moins accessibles, et bien plus problématique pour l’interopérabilité entre différents systèmes d'exploitations.

    • [^] # Re: Toujours le souci des débits...

      Posté par  . Évalué à 7.

      peut-être un tweak ? il y a un module kernel pour ça. Je dirais que ça va changer la donne sur la perf ( https://www.kernel.org/doc/html/latest/filesystems/cifs/ksmbd.html ) mais je n'ai pas tester

    • [^] # Re: Toujours le souci des débits...

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

      Normalement il ne doit pas y avoir de soucis pour saturer un lien Gigabit via SMB, sauf si le montage est fait via FUSE (ce qui se fait lorsqu'on monte le partage depuis le gestionnaire de fichier) : pour avoir un débit optimal, il faut monter donc le partage avec la commande mount.

    • [^] # Re: Toujours le souci des débits...

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

      SMB n'a pas le même usage que NFS, SSHFS, iSCSI. Il provient du monde de Windows et l'objectif initial était de permettre à tout les ordinateurs d'un même workgroup de ce voir et d'échanger des fichiers. Ensuite sont venu l'authentification, la couche DNS, les GPO…

      NFS il faut connaitre à l'avance la machine que tu souhaite atteindre, ensuite connaitre le nom du point de montage. C'est parfait pour de l'échange entre serveurs, mais pas vraiment exploitable au quotidien par un utilisateur.

      SSHFS pour moi c'est pour transférer un fichier à un moment précis.

      iSCSI, tout comme NFS c'est pour de l'échange entre serveurs à un niveau inférieur en mode block.

      Born to Kill EndUser !

  • # Partir à neuf..

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

    demain matin je pars une entreprise et je vieux rien de ms dedans…

    il y a quoi comme outil

    pour gérer les accès, imprimante, installer des logiciels et les pousser sur les postes…
    bref gérer un parc informatique?

    www.solutions-norenda.com

    • [^] # Re: Partir à neuf..

      Posté par  . Évalué à 1.

      Vaste question.
      Pour les imprimantes modernes, elles sont souvent en réseau et ne nécessite pas de samba.
      Pour le partage de fichier Unix/Linux, il y a NFS et ça gère très bien les droits utilisateurs.
      Après niveau admin pour les logiciels, avec des scripts du SSH etc… ça se fait très bien

      • [^] # Re: Partir à neuf..

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

        bref un ramassis d'outils à droite et à gauche…. pas top quand tu as des centaines de postes, voir des milliers à gérer…

        www.solutions-norenda.com

        • [^] # Re: Partir à neuf..

          Posté par  (site web personnel) . Évalué à 5. Dernière modification le 15 juin 2022 à 02:19.

          bref un ramassis d'outils à droite et à gauche

          Non.

          Pour un contrôleur de domaine AD tu as besoin de :

          • Samba (LDAP, Kerberos, DNS)
          • un serveur NTP, par exemple ntpsec
          • un serveur DHCP, par exemple dnsmasq

          Perso je surcharge le DNS minimaliste de Samba avec dnsmasq car je préfère gérer les domaines dans des fichiers plats et dnsmasq est pratique pour pouvoir déclarer nom, mac et ip sur une même ligne. J’ai d’ailleurs soumis un patch (désormais fusionné) à Samba pour simplifier la mise en œuvre d’une surcharge de Samba par dnsmasq (vivement que le patch arrive dans les distros !).

          Pour la distribution de logiciels il y a différents outils, mais en fait faire du SSH sur toute les machines ça marche très bien, surtout qu’avec le Samba il te suffit de créer un utilisateur que t’ajoutes au groupe Administrator et de déployer à la première installation de la machine un fichier sudoers qui rend tous les membres du groupe Administrator capable de faire sudo et hop, tu peux ssh toutes tes machines avec le même compte.

          Perso je fait même ça sous Windows tellement c’est pratique et j’ai laissé tombé les trucs de déploiement à la OCS.

          Pour l’authentification côté client Linux il faudra PAM et certains modules particuliers, une fois PAM configuré correctement les dossiers utilisateurs sont créés automatiquement à la première authentification et après ça il devient même possible de s’authentifier sans réseau.

          Pour le partage de fichier, voir mon autre commentaire.

          Pour les imprimantes, autant acheter des imprimantes qui font réseau directement, sinon il y a CUPS (mais franchement… autant acheter une imprimante réseau).

          Après, c’est un métier. La configuration par défaut ne fait clairement pas tout ça. Si besoin je suis spécialisé dans ce domaine : https://rebatir.fr/

          C’est robuste, ça marche très bien avec des centaines de machines, y compris séparées par des VPNs, et ça répond aux besoins.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Partir à neuf..

            Posté par  . Évalué à 2.

            Bonjour Thomas,

            Cette surcharge du DNS interne samba par dnsmasq est elle documentée quelque-part sur le wiki samba ?

            J'ai mis en place les deux lignes de conf précisées dans la discussion liée au patch (fichiers smb.conf et dnsmasq.conf) mais cela plante systématiquement mon service dnsmasq (test sous Fedora Server 36 avec samba 4.16.2).

            • [^] # Re: Partir à neuf..

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

              J’ai ajouté la partie spécifique à samba à la doc samba mais je ne sais pas si ça arrive sur un site en ligne (pas sur le wiki on dirait). Et je n’ai pas ajouté au wiki samba, c’est une bonne idée.

              Normalement ces deux lignes sont suffisantes. J’ai peut-être fait une faute de frappe: C’est peut-être un # au lieu d’un : pour le port (cf. dnsmasq.conf.example).

              # dnsmasq.d/server.conf
              server=/local-domain.example.com/127.0.0.1#54
              
              # smb.conf
              dns port 54
              

              Aussi (histoire d’éviter toute confusion), je suppose que local-domain.example.com soit le parent (pas le nom de la machine).

              Par exemple si ton réseau s’appelle mycompany.org et que ton serveur AD samba s’appelle choucroute, le FQDN du serveur est choucroute.mycompany.org, et la configuration dnsmasq sera:

              server=/mycompany.com/127.0.0.1#54
              

              Mais si le FQDN de ton serveur AD est choucroute.intra.mycompany.org, alors la configuration dnsmasq sera:

              server=/intra.mycompany.com/127.0.0.1#54
              

              Bien sûr en supposant que le dnsmasq et la samba-ad-dc sont sur la même machine.

              ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Partir à neuf..

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

          Merci de ne pas prendre de haut ce contributeur, car il reflète les questions avancées par mes chefs pour rester en "tout m$". Cette attitude est d'ailleurs révélatrice, les choses ne sont toujours pas prêtes de changer donc… même si un vote pour la Nupes Dimanche peut aider un tout petit peu…

          • [^] # Re: Partir à neuf..

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

            Je ne sais pas trop à qui tu réponds parce que je ne vois pas ce qui dans ta réponse, semble rebondir sur le commentaire auquel tu réponds directement. Tout comme je ne vois pas du tout le rapport avec la Nupes.

            En tout cas, il est légitime de se poser des questions avant de choisir Linux ou Windows ou de passer de l’un à l’autre. Windows donne l’illusion que c’est facile parce que tout le monde a un Windows chez soi. C’est d’ailleurs un point que je me suis rendu compte en me retrouvant face à certains décideurs : ils ouvrent leur Windows, ils éditent et enregistrent des fichiers, c’est comme chez eux ! Sauf que non c’est pas comme chez eux, les données ne sont pas sur l’ordinateur, l’ordinateur pourrait être remplacé qu’ils ne le sauraient pas, ils peuvent aller sur le poste d’à côté dans le bureau d’à côté sur lequel ils ne sont jamais allé et taper le même mot de passe et récupérer le même bureau avec les mêmes fichiers dans les mêmes dossiers, et ils peuvent aller dans tel dossier pour récupérer le fichier dans la version d’il y a une heure parce qu’ils l’ont supprimé par mégarde, mais ils ne s’en souviennent que quand ils appellent pour retrouver leur fichier et oublient aussitôt !

            Sur Linux il y a peut-être un peu plus de travail à la configuration d’un AD que sous Windows car déjà il faut le configurer pour mettre en œuvre un AD avant de configurer les paramètres eux-même. Car les outils sont plus génériques : prenons le paquet dnsmasq par exemple, il est généralement installé en dépendance quand on installe qemu pour virtualiser des systèmes, sauf que la configuration d’un dnsmasq pour qemu n’est pas tout à fait la même que la configuration d’un dnsmasq pour administrer un parc informatique, pourtant le paquet est le même. Donc il faut spécialiser la configuration des paquets. Mais une fois ceci fait, l’administration au jour le jour me semble plus simple. Sous Windows tout se fait à coup de fenêtres toujours différentes et dont la signification n’a pas beaucoup de sens pour qui n’a pas compris un minimum comment ça marche en dessous, de toute façon.

            Donc le décideur pourrait bien choisir de faire du Windows parce que ça lui parait plus simple, sauf que les centres de formations sont pleines de formations à ces outils Microsoft, parce qu’il y a besoin de formation, Windows ou non.

            Au final les outils équivalents sous Linux sont robustes, fiables et éprouvés. La spécialisation initiale est spécifique, mais la logique d’administration est la même. J’apprécie de pouvoir versionner la configuration sous Linux.

            Je me demande par contre s’il y a pas une place pour une “saveur” spécifique d’une distro qui soit prête pour ça (AD, serveur de fichier, client), un peu de la même manière que Proxmox fournit une Debian prête à l’emploi avec leurs paquets et qu’on a plus qu’à l’installer comme ça. Et puis ça ne serait qu’une Debian avec que des paquets Debian (ou quasiment, parfois c’est pratique d’avoir tel ou tel paquet plus récent), mais avec une configuration spécifique. Par contre je ne sais pas s’il y a moyen de financer ça. C’est du boulot de faire un produit générique qui est parfaitement reproductible chez n’importe qui en fermant les yeux…

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Partir à neuf..

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

              Le point à ne pas négliger est la contrainte éditeur. Par exemple j'ai à 80% un parc serveurs en Linux, le reste est composés de Windows parce que telle ou telle logiciel fonctionne uniquement sur un environnement Windows et qu'il n'existe pas d'alternative viable dans l'univers de l'OpenSource (paie, pointeuse…).

              Tu peux choisir Linux pour la partie système et réseau (DNS, DHCP, authentification… Bref l'invisible pour l'utilisateur) mais pour le reste tu dois composer avec le besoin, ce qui est dispo sur le marché et tes convictions.

              Born to Kill EndUser !

              • [^] # Re: Partir à neuf..

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

                Oui tout à fait. J’ai eu des parcs où 100% du l’infra serveur/routeur/etc. était sous Linux et 99% des bureaux était du Windows (avec deux trois linux et macs minoritaires). Ce qui est certain est qu’on peut tout à fait avoir un parc 100% Windows sur les postes de travail, que ce soit à cause des besoins applicatifs, de certains matériels spécifiques (j’ai travaillé pour une exploitation viticole par exemple, je ne crois pas que l’imprimante d’étiquette à bouteille avait un pilote Linux :D), et avoir l’intégralité de l’infra de service sous Linux.

                Et si besoin, rien n’empêche d’avoir une machine virtuelle pour un besoin spécifique. Par exemple on peut très bien avoir un « manager » d’antivirus dans une machine virtuelle Windows pour administrer les antivirus clients sur les postes Windows, mais la gestion du réseau, des droits, le stockage, que tout soit géré sous Linux.

                Ce qui est certain c’est qu’avoir un parc utilisateur 100% Windows n’est pas du tout un argument en défaveur d’avoir une infra Linux, « on a déjà du Windows sur les postes » ou « il nous faut du Windows sur les postes » n’est pas un argument contre Linux sur les serveurs. De toute façon le décideur qui dirait ça pourrait acheter un Synology parce que quelqu’un lui en a parlé ou qu’il en a un à la maison, sans se rendre compte que c’est un Linux+Samba dedans (la magie de la boîte noire avec une belle étiquette qui, parce qu’elle forme un « produit », se soustrait à tous les discernements ordinaires).

                En soi être confronté à un parc de postes de travail 100% Windows est très instructif car Microsoft a bien dû apporter des solutions à des problèmes réels de leurs clients réels, donc autant appliquer les mêmes méthodes si elles fonctionnent, quand elles font sens et qu’elles sont éprouvées, plutôt que réinventer la roue. Ça n’a d’ailleurs plus vraiment de rapport avec la question libre/pas libre puisqu’aujourd’hui des outils comme Samba existent. Bon il y a des trucs qui m’énervent un peu dans l’infra Windows, mais si on m’interdisait d’utiliser Samba je ne vois pas pourquoi je devrais faire sans une infra NTP/DHCP/LDAP/Kerberos, que l’identifiant s’appelle samAccountName au lieu d’username est une windowserie dont je me passerai bien mais bon 🤫️…

                À noter que passer à une infra de type AD que ce soit avec Samba ou Windows Server peut apporter des problèmes, mais c’est pas la faute de Samba, les problèmes sont les mêmes sous Windows : des tas d’applications ne sont pas pensées pour un environnement d’entreprise de ce genre. Par exemple certaines applications enregistrent des préférences ou des données dans AppData/Local au lieu de AppData/Roaming, je ne sais pas où ça en est mais par exemple il y a quelques années j’avais remarqué chez un utilisateur que même l’application « post-it » de Windows enregistrait ses données dans AppData/Local qui est un cache local à la machine qui est donc sensé être jetable et pouvoir être perdu avec la machine ! Qt fait la même erreur à cause de ce qui semble être une mauvaise interprétation de la documentation et une formulation hasardeuse (ça impacte donc les applis KDE sous Windows). J’ai aussi vue une application de bureau à distance (type TeamViewer mais une autre dont j’ai oublié le nom) qui calculait son identifiant d’accès à une machine sur la base de l’utilisateur, sauf qu’avec un AD l’utilisateur est le même quelque soit la machine, dont il n’était pas possible d’accéder à telle ou telle machine si le même identifiant avait ouvert deux machines 🤦‍♀️️. Bref, il y a tout un pan de l’informatique, y compris des produits de Microsoft, qui ne sont pas testés sur un réseau d’entreprise. Je n’ai jamais rien vu de bloquant, mais ça fait toujours bizarre de faire ce genre de surprise. Ça plus certaines applications métiers sous Windows qui ne sont pas testées sur des machines qui ne tournent pas en super utilisateur 🤦‍♀️️… Rien que ne pas être administrateur sans capacité d’escalade peut encore casser des choses en 2020+. Mais Windows ou Linux/Samba ça sera pareil de toute façon.

                ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Partir à neuf..

              Posté par  . Évalué à 2.

              Il y a des distributions toutes prêtes, voir la liste en bas de https://infolib.re/Integrer_un_ordinateur_Linux_Mint_dans_un_domaine_Active_Directory

            • [^] # Re: Partir à neuf..

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

              Moui bizarre, peut-être que le commentaire un peu limite a été supprimé? Pour la Nupes, je faisais allusion au fait que beaucoup des candidats sont pour rendre le libre vraiment obligatoire.

  • # Samba au détriment de...

    Posté par  . Évalué à 0.

    Pour commencer, je trouve très bien l'existence de Samba qui permet l’interopérabilité entre les unix/linux et windows.
    Je trouve regrettable en revanche, notamment sur les box internet avec des linux embarqués qu'on ne puisse profiter de NFS..
    Samba entre linux me laisse dubitatif. Et je trouve assez bizare le nombre de tutos pour du partage entre linux de privilégier du samba…

    • [^] # Re: Samba au détriment de...

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

      Samba entre linux me laisse dubitatif. Et je trouve assez bizare le nombre de tutos pour du partage entre linux de privilégier du samba…

      Peut-être parce que, sauf erreur de ma part, NFS ne propose pas de "vraie" authentification, sauf si on y ajoute Kerberos (ce qui est loin d'être trivial) ?

    • [^] # Re: Samba au détriment de...

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

      Parce que l’écosystème est éprouvé. Un Samba c’est un annuaire d’utilisateur dans un LDAP et une authentification avec Kerberos, et le partage de fichiers qui va avec. Avec PAM, etc. tu peux même avoir de l’authentification itinérante (où tu peux ouvrir ta session sur ton ordi portable alors que t’es déconnecté du réseau).

      Pour la gestion des fichiers, tout est très bien géré y compris la copie côté serveur avec copie clone (NFS le fait peut-être, j’en sais rien, mais c’est pour dire que Samba répond au besoin), et Samba apporte des fonctionnalités très pratiques, comme la capacité à ne pas lister les fichiers et dossiers non-lisibles : c’est très pratique parce que tu peux mettre tous tes dossiers partagés dans le même dossier parent et les utilisateurs ne verront pas les dossiers auxquels ils n’ont pas accès.

      Il y a un domaine dans lequel je privilégie parfois NFS sur Samba c’est quand le client est un client macOS. Par exemple NFS est meilleur sur macOS pour compiler sur le réseau.

      Mais sinon Samba apporte beaucoup de solutions. Aussi, Samba propose une architecture bien déterminée, qu’on aime ou on aime pas qu’elle ait été définie par MS, ça veut dire qu’elle est éprouvée et répond à beaucoup de besoins que tu n’imagines pas encore.

      Tu pourrais tout refaire avec des composants séparés mais le rapport coût/gain ne serait pas très avantageux.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Samba au détriment de...

        Posté par  . Évalué à 1.

        Avec PAM, etc. tu peux même avoir de l’authentification itinérante (où tu peux ouvrir ta session sur ton ordi portable alors que t’es déconnecté du réseau).

        Quand tu ouvre une session en itinérance, je suppose que tu n'obtiens pas de ticket Kerberos puisque le serveur n'est pas joignable. Est-ce qu'il y a un moyen ensuite de récupérer automatiquement un ticket avec les informations fournies initialement à PAM, sans saisir à nouveau login/password, quand le serveur Kerberos redevient joignable, par exemple après connexion VPN ?

        • [^] # Re: Samba au détriment de...

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

          Aux dernières nouvelles il faut refaire un kinit en effet, je me demande aussi si ce kinit peut réutiliser les informations initialement fournies à la connexion. Ça fait partie des choses que je comptes investiguer pour que l’expérience soit plus “lisse”, même si en soit, tester si le réseau est là, si le ticket est absent, et faire surgir un formulaire le cas échéant n’est pas très compliqué.

          ce commentaire est sous licence cc by 4 et précédentes

  • # Video sur samba AD

    Posté par  . Évalué à 2.

    Je suis tombé il y a deux jours sur cette vidéo expliquant bien ce qu'on peut faire avec Samba AD.
    https://www.youtube.com/watch?v=oi9WaUBzljc

    Je ne savais pas qu'autant de structures utilisaient Samba en remplacement de MS AD…

Suivre le flux des commentaires

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