Publication de Samba 3.2

Posté par (page perso) . Modéré par Nÿco.
Tags :
0
9
juil.
2008
Samba
L'équipe de développeurs de Samba a sorti le 1er juillet dernier en toute discrétion la version 3.2 du logiciel permettant d'assurer la compatibilité d'UNIX avec les protocoles réseaux propriétaires de Microsoft et IBM que sont Netbios, SMB et CIFS. Le nouveau gestionnaire de publication est Karolin Seeger qui travaille à plein temps sur Samba au sein de la société SerNet GmbH. Cette version est désormais publiée sous licence GNU GPL v3.

Au niveau des améliorations apportées, vous trouverez :
  • grâce au backport de la bibliothèque ctdb de la branche 4.0, Samba 3.2 est désormais capable de fournir une solution de serveurs de fichiers clusterisés ;
  • Samba intègre désormais la prise en charge de configuration de type registre, ceci afin de permettre le paramétrage de manière plus simple qu'en parcourant et en modifiant un fichier de configuration ;
  • Samba est désormais parfaitement compatible avec Windows Vista SP1 et Windows Server 2008 ;
  • La gestion des partages chiffrés en se basant sur l'API GSSAPI ; cette innovation est d'ailleurs disponible uniquement grâce à Samba qui a fait le choix de proposer une extension du protocole CIFS ;
  • Optimisations de l'empreinte mémoire via l'utilisation de la bibliothèque talloc ;
  • Compatibilité IPv6 complète suite à la réécriture d'une partie du code dans cette optique.
  • # Compatibilité Vista, toussa

    Posté par . Évalué à 7.

    sans vouloir rentrer dans les débats associés, la compatibilité avec Vista &co est une excellente nouvelle, c'était vraiment problématique jusqu'à maintenant, surtout à l'échelle professionnelle.
    • [^] # Re: Compatibilité Vista, toussa

      Posté par . Évalué à 7.

      Une amélioration de l'interopérabilité est toujours un point positif, et Samba représente un bon moyen de remplacer une "brique microsoft" par une "brique libre" dans les pme...
      • [^] # Re: Compatibilité Vista, toussa

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

        > Une amélioration de l'interopérabilité

        Euh tu veux dire compatibilité !
        • [^] # Re: Compatibilité Vista, toussa

          Posté par . Évalué à 5.

          Vu qu'il s'agit de protocoles utilisés dans le cadre de services réseau avec un interfaçage étudié et créé volontairement pour supporter un dialecte, on peut parler d'interopérabilité non?
          • [^] # Re: Compatibilité Vista, toussa

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

            > Vu qu'il s'agit de protocoles utilisés dans le cadre de services réseau avec un interfaçage
            > étudié et créé volontairement pour supporter un dialecte, on peut parler d'interopérabilité
            > non?

            Samba parle le dialecte "Netbios", "SMB" et "CIFS" depuis la création du projet. Ce qui est nouveau c'est qu'il n'était pas compatible à un système donnée et une version spécifique. On parle de compatibilité.

            Intéropérabilité = tout le monde parle le même langage
            Compatibilité = on modifie le comportement pour parler a un système/logiciel spécifique et uniquement pour lui (il ne s'agit pas de modification de protocole ouvert ou standard).

            Pour prendre un autre exemple :

            html = interopérabilité des navigateurs (tous le monde code le même format ouvert)
            mshtml = compatibilité des navigateurs (les navigateurs adaptent leur moteur de rendu pour proposer un rendu spécifique à un moteur de rendu concurrent spécifique).

            Après tu peux ne pas voir la différence, mais je peux rien y faire.
            • [^] # Re: Compatibilité Vista, toussa

              Posté par . Évalué à 10.

              Dommage, réponse presque parfaite, s'il n'y avait pas la dernière ligne.

              Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

              • [^] # Re: Compatibilité Vista, toussa

                Posté par . Évalué à 3.

                il y a aussi la définition de l'ISO pour l'interopérabilité en informatique:

                "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".


                A mon humble avis, eux non-plus n'ont rien compris...
            • [^] # Re: Compatibilité Vista, toussa

              Posté par . Évalué à 2.

              Pour ma part, je partais de ceci...

              http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9

              Il convient de distinguer « interopérabilité » et « compatibilité ». Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.

              dans la mesure où il s'agit d'une avancée dans la connaissance des interfaces...

              Mais bon, libre à toi de continuer ton débat improductif.
              • [^] # Re: Compatibilité Vista, toussa

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

                J'aurais préféré que tu copie colle la 1er phrase avec. La 2eme étant un éclaircissement de la 1er :

                L’ interopérabilité est la capacité que possède un produit ou un système dont les interfaces sont intégralement connues à fonctionner avec d'autres produits ou systèmes existants ou futurs.

                Sinon, cela voudrait dire que word et son .doc est un exemple d'interopérabilité.
            • [^] # Re: Compatibilité Vista, toussa

              Posté par . Évalué à 2.

              Intéropérabilité = tout le monde parle le même langage

              Je dirais plutôt que:
                      Intéropérabilité = tout le monde se comprend (par l'intermédiaire de traducteurs s'il le faut)

              Car il ne faut pas se leurrer, l'intéropérabilité n'est pas nécessairement libre et gratuite...
              • [^] # Re: Compatibilité Vista, toussa

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

                Concernant les formats ouverts, l'interopérabilité, ... j'aime bien me référer à Thierry Stœhr.

                Plus qu'un long discours, voici ce qu'il dit sur l'interopérabilité : http://formats-ouverts.org/blog/2006/12/15/1040-une-page-htm(...)

                Pour moi, samba<->windows xxx correspond plus au schéma 2 (le standard de fait dans les formats ou les protocoles) que au schéma 3 (l'interopérabilité des formats ou des protocoles).

                Après il faut savoir ce qu'on entend par interopérabilité. Est-ce que passé des heures a comprendre le fonctionnement d'un protocole, a faire du reverse engineering, de l'analyse de trame, ... permet de "rendre compatible un logiciel a un autre" ou de leinteropérabilité ? Personnellement je pense pense que c'est uniquement pour le rendre "compatible".
          • [^] # Re: Compatibilité Vista, toussa

            Posté par . Évalué à 2.

            avec un interfaçage étudié et créé volontairement pour supporter un dialecte
            Ca veut dire quoi cette phrase ?
    • [^] # Re: Compatibilité Vista, toussa

      Posté par . Évalué à 1.

      Et bien c'est tant mieux, car V$ and Co a de gros problèmes de compatibilité avec un serveur en 2000 pourtant issu de la même boîte.

      A tel point qu'il n'est pas difficile de l'interdire en entreprise, pas plus que de migrer vers autre chose...pardon : Linux bien sûr.

      Les coûts en monnaie trébuchante et sonnante aussi bien, et surtout , les coûts en jours-homme étant largement en faveur d'un système GNU/Linux.

      Et pour les grincheux, il n'y a pas photo même en comptant la formation.
  • # Registre de configuration : plus simple ?

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

    Samba intègre désormais la prise en charge de configuration de type registre, ceci afin de permettre le paramétrage de manière plus simple qu'en parcourant et en modifiant un fichier de configuration

    Un registre de configuration, c'est plus simple qu'un fichier... C'est objectif, cet avis ?
  • # Partage de fichier "portable"

    Posté par . Évalué à 3.

    Sous Windows il y a CIFS anciennement SMB, sous Mac OS on trouve AppleShare/AppleTalk, Unix possède SSH, NFS, SCP, ....

    Cependant, Windows faisant la sourde oreille à tout protocole ne lui appartenant pas, la seul solution viable pour partager des fichiers entre plusieurs systèmes reste Samba...

    Cela n'est-il pas un avantage pour Microsoft qui voit sont protocole (fermé) utilisé un peu partout ?

    Cela dit un grand merci au projet Samba qui est vraiment utile dans ma vie de les jours mais dommage qu'il ne s'agisse pas d'un protocole un peu plus ouvert :(
    • [^] # Re: Partage de fichier "portable"

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

      Heu, pour partager des fichiers, FTP fonctionne très bien partout non?
      • [^] # Re: Partage de fichier "portable"

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

        Hum... Le chariot à boeuf aussi fonctionnait très bien... Pourquoi utiliser une voiture ?
        • [^] # Re: Partage de fichier "portable"

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

          Tu veux dire que samba accélère le transfert de fichier?
          • [^] # Re: Partage de fichier "portable"

            Posté par . Évalué à 8.

            Plutôt que le transfert est facilité par ce type de protocole je trouve personnellement la mise en place et l'utilisation de FTP un peu plus lourde... Avec Samba tout comme NFS le parcours d'un dossier distant se fait comme en local...

            Bon d'accord c'est possible de le faire avec VFS pour FTP mais je trouve que FTP n'est pas vraiment prévu pour cet usage...
            • [^] # Re: Partage de fichier "portable"

              Posté par . Évalué à 8.

              Surtout, FTP est un protocole du siècle passé, avec des limitations qui s'accordent mal aux réseaux actuels (problèmes avec le NAT et les firewalls principalement), et une sécurité très faible (mot de passe transmis en clair). Ce protocole est à éliminer au plus vite...
              • [^] # Re: Partage de fichier "portable"

                Posté par . Évalué à 5.

                Ce protocole est à éliminer au plus vite...

                Ou à utiliser dans une de ses variantes SSLisées pour tout ce qui n'est pas anonyme. C'est correctement géré par suffisamment de clients et de serveurs libres pour que l'on s'en prive.
                • [^] # Re: Partage de fichier "portable"

                  Posté par . Évalué à -3.

                  Pas mal comme logique. Comme Windows est utilisé par beaucoup de personnes, c'est suffisant pour qu'on s'en prive aussi, alors ? :-)
                • [^] # Re: Partage de fichier "portable"

                  Posté par . Évalué à 2.

                  Le manque de sécurité n'est que le moindre des défauts du FTP... S'il n'y avait que ça, on pourrait effectivement se contenter d'utiliser SSL, mais c'est la conception même du protocole qui fait qu'il n'est plus adapté aux contraintes des réseaux actuels.

                  Bref, à part quand la compatibilité avec quelque chose d'existant est primordiale, FTP ne devrait plus être utilisé. Quand il s'agit de mettre des fichiers à disposition de tout le monde, HTTP fait parfaitement l'affaire, et quand l'envoie de fichiers est nécessaire, SFTP est nettement meilleur.
                  • [^] # Re: Partage de fichier "portable"

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

                    Avec SFTP tu vas chiffrer tes données, c'est complètement ridicule pour des données que tu veux diffuser publiquement, ce sera plus lent et consommera plus d'énergie.
                    • [^] # Re: Partage de fichier "portable"

                      Posté par . Évalué à 2.

                      C'est pour ça que je parle d'HTTP pour les trucs qu'on veut diffuser publiquement...
                      • [^] # Re: Partage de fichier "portable"

                        Posté par . Évalué à 2.

                        HTTP n'est pas vraiment pensé pour de la diffusion de gros fichiers, non plus, ce me semble.
                        • [^] # Re: Partage de fichier "portable"

                          Posté par . Évalué à 4.

                          Même s'il est pas forcément conçu pour, il le fait très bien quand même, tout aussi bien que FTP en fait (d'ailleurs, beaucoup de mirroirs de FTP publics sont aussi accessibles en HTTP, par exemple [http://mirror.switch.ch/ftp/mirror])

                          On a tout ce qu'il faut pour : transfert en binaire brut (pas d'encodage qui augmenterait le volume de données), et possibilité d'arrêt/reprise du téléchargement.

                          En plus de ça, c'est un protocole qui passe sans soucis tous les NAT/firewalls (au contraire du FTP, même anonyme)
                      • [^] # Re: Partage de fichier "portable"

                        Posté par . Évalué à -2.

                        L'"HyperText Transfer protocol" est moins efficace car entièrement basé sur du tcp. Le FTP utilise l'udp, ce qui lui permet d'avoir un meilleur ratio "données utiles"/"trafic de gestion" et de moins saturer le réseau inutilement...

                        Maintenant, encore une fois, les protocoles web ne sont pas des remplacements pour des protocoles "entreprise" et le ftp n'a pas grand chose à faire dans cette discussion... La contrepartie unix du cifs, c'est le nfs, pas le ftp.
                        • [^] # Re: Partage de fichier "portable"

                          Posté par . Évalué à 2.

                          FTP est aussi complètement basé sur TCP (cf RFC 959 [http://www.faqs.org/rfcs/rfc959.html])
                        • [^] # Re: Partage de fichier "portable"

                          Posté par . Évalué à 2.

                          La contrepartie unix du cifs, c'est le nfs, pas le ftp.

                          Tout dépend de l'usage de CIFS dont il est la contrepartie. Il y a bien des entreprises où l'on utilise le partage réseau comme un FTP à peine amélioré (juste intégré à explorer, en fait).

                          Le genre "stockage d'archives", par exemple.
                        • [^] # Re: Partage de fichier "portable"

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

                          Heureusement que c'est faux!

                          Voila là chose qu'il faut que tu retiennes à tout prix pour ton cours de réseau : «TCP c'est fiable, si je veux du fiable, j'utilise TCP». Tu pourras fièrement l'énoncer à ton prof de réseau qui te congratulera d'une petite tape bienveillante sur la tête.
                          • [^] # Re: Partage de fichier "portable"

                            Posté par . Évalué à 3.

                            ça changera des tapes condescendantes de ta part, c'est sûr...
                          • [^] # Re: Partage de fichier "portable"

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

                            > si je veux du fiable, j'utilise TCP

                            ça, il ne faudra pas lui dire trop fort, à ton prof de réseau.
                            • [^] # Re: Partage de fichier "portable"

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

                              Pourquoi? Je veux bien recevoir une leçon si tu veux bien prendre le temps de m'expliquer. :)
                              • [^] # Re: Partage de fichier "portable"

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

                                TCP est _un_ moyen d'avoir une connexion fiable, mais tu peux tout à fait ajouter l'équivalent dans la couche applicative. L'intérêt étant que l'application peut savoir mieux que le protocole quoi faire quand on perd un paquet, mais par contre, ça fait plus de boulot pour l'applie.

                                Par exemple, NFS peut tourner sur du UDP, je ne retrouve pas précisément, mais je suis 99% sur qu'il y a un méchanisme de checksum comparable à celui de TCP, et « man nfs » par le méchanisme de ré-émisson de requetes NFS quand elles sont perdues.
                                • [^] # Re: Partage de fichier "portable"

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

                                  Okay, effectivement c'est vrai que quand on utilise UDP, si l'on veut une gestion de la fiabilité elle doit être implémenté dans la couche applicative, donc il est tout à fait possible de faire du fiable avec UDP.

                                  Puisque tu as l'air de connaître un peu le sujet, est que tu serais me dire si au niveau performance cela est équivalent ? Bien sûr c'est fortement dépendant de comment on code la gestion...

                                  Moi ce que j'avais retenu c'est que UDP est plutôt à utilisé dans les cas où on s'en fou de perdre des paquets, par exemple pour le streaming audio/video : si un paquet c'est égaré, tant pis, on continue sans l'important étant de permettre un rendu temps réel aussi fluide que possible.

                                  En tout cas merci pour ton rappel. :)
                                  • [^] # Re: Partage de fichier "portable"

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

                                    Puisque tu as l'air de connaître un peu le sujet, est que tu serais me dire si au niveau performance cela est équivalent ? Bien sûr c'est fortement dépendant de comment on code la gestion...

                                    Je connais pas particulièrement ;-).

                                    Niveau performance, oui, ça dépends comment tu gère les pertes de paquets. Pour NFS, j'ai souvenir d'avoir lu dans le man que TCP était plutôt plus rapide vu que la ré-émisson en cas de perte se faisait au niveau paquet alors qu'en UDP c'était au niveau requete, mais j'ai un man différent sous la main qui ne parle pas de ça, et qui dit qu'UDP est le défaut, il doit y avoir une raison !

                                    Sinon, un protocole non-fiable peut aussi être utilisé dans les cas où tu sais traiter les paquets dans le désordre : un paquet perdu ne t'empêche pas de continuer à traiter ce qui arrive au fur et à mesure et attendant la ré-émission.
                                • [^] # Re: Partage de fichier "portable"

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

                                  UDP inclut une somme de contrôle du paquet complet, qui est jeté s'il n'est pas conforme.

                                  C'est d'ailleurs la raison d'être d'UDP Lite, si je me souviens bien. Il permet de restreindre cette somme de contrôle au début du paquet, sur une longueur arbitraire, notamment aux seuls en-têtes.
              • [^] # Re: Partage de fichier "portable"

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

                Personnellement je me verrais mal arrêter d'utiliser des protocoles du «siècle passé» dont font partie http, ftp, tcp, udp, IP(v4) et un tas d'autres.

                Bien sûr qu'au niveau confidentialité ce n'est pas ça, mais tu peux utiliser sftp si tu veux du chiffrement.

                Il serait bon aussi de prendre ma remarque dans son contexte : e répondais à la phrase «la seul solution viable pour partager des fichiers entre plusieurs systèmes reste Samba» qui me semble erroné, pour le partage de fichier multi-plateforme, ftp fait très bien l'affaire, exemples :
                ftp://download.tuxfamily.org/cls/
                ftp://ftp.gnu.org/
                ftp://ftp.free.fr/
                ftp//ftp.etc.org/

                Je n'ai rien dit de samba que je n'ai jamais utilisé car je n'en ai jamais eu l'utilité, mais samba fait plus que le partage de fichier pour le peu que j'en sais (partage d'imprimantes par exemple).
                • [^] # Re: Partage de fichier "portable"

                  Posté par . Évalué à 5.

                  HTTP, tcp, udp n'ont pas les défaut de FTP.

                  Mon reproche est spécifiquement dirigé contre FTP. Le problème est qu'il a besoin de 2 connexions, et la deuxième pose des tas de problèmes. Dans le cas où elle est créée dans le sens serveur => client (FTP actif), ça ne passe pas le NAT (ou alors avec réécriture des paquets sur le routeur), dans le sens client => serveur (FTP passif), ça pose problème au niveau du serveur si on veut mettre un firewall un peu restrictif. Bref, FTP est un mauvais protocole, pas parce qu'il a été conçu au siècle passé, mais parce qu'il s'adapte mal aux contraintes des réseaux actuels, et c'est pour cette raison qu'il faudrait éviter de l'utiliser.

                  Quand il s'agit de mettre des fichiers à disposition de tout le monde (FTP anonyme), on peut parfaitement utiliser HTTP.

                  SFTP est très bien, mais à part le nom et la fonction, ce protocole n'a strictement rien à voir avec FTP, il est basé sur SSH et n'utilise qu'une seule connexion, ce qui fait qu'il n'a pas les défaut que je cite au dessus.
                  • [^] # Re: Partage de fichier "portable"

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

                    > ça ne passe pas le NAT

                    Le problème est que c'est le NAT qui est mauvais pas FTP.

                    Le NAT n'apporte aucune sécurité, que des emmerdements. Le réseau internet a été conçu pour faire du point à point entre tous les membres du réseau.

                    Le NAT ne fait que retarder IPv6. Sans NAT, on aurait déjà IPv6.

                    Le FTP est un protocole en clair. Certe, le fait d'utiliser un double port est merdique (d'un point de vu d'aujourd'hui) mais n'importe quel firewall aujourd'hui sais suivre un connexion FTP.

                    Bref, je te trouve trop sévère vis à vis du FTP qui a rempli et qui remplit encore une tâche utile.

                    Par contre, je ne comprends pas comment on peut faire les protocoles suivants qui sont bien moins anciens et qui sont 100 fois plus merdique que le FTP :

                    - H323, ok c'est pas tout jeune et ca dérive des téléphonistes mais bonjours les ports. Va trouver un firewall qui filtre correctement une multi-session sur un pont + gatekeepers sur H323. Il n'y en a pas tant que cela qui marche vraiment.

                    - SIP, le concurrent du H323 qui vient des informaticiens. Une daube inconcevable de la part d'informaticien. C'est pas croyable que des gars ai pu pondre un truc pareil.

                    Bref, il y a de vieux protocole qui ont été conçu pour un internet sans NAT (et il ne devrait pas y avoir de NAT) qui ne sont pas si compliqué que cela et il y a des protocoles jeunes qui sont nés avec le NAT et qui n'aurait pas du voir le jour...

                    Laissons le FTP mourrir tranquillement comme gopher. Respect le FTP.
        • [^] # Re: Partage de fichier "portable"

          Posté par . Évalué à 6.

          «about:black sur les navigateurs ! (Sauvons la planète)»

          Ça c'est nimportenawak ;-)
      • [^] # Re: Partage de fichier "portable"

        Posté par . Évalué à 1.

        ftp, c'est un protocole qui sent bon le bureau de papy, les vieux meubles en bois et les postes à lampes... c'est un protocole du temps jadis où il n'était pas encore question d'authentication forte, de sécurité, ...

        Dans le monde moderne, on a des protocoles un peu mieux comme le nfs4 avec les extensions kerberos, le cifs, voir même sftp et les autres dérivés de ssh, ...
        • [^] # Re: Partage de fichier "portable"

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

          Oui mais bon tout dépend de ce dont on parle encore une fois.

          C'est pas parcequ'un protocole est ancien qu'il est mauvais. Au contraire il y a de bonnes chances qu'il soit robuste et efficace dans le cadre des utilisations pour lesquelles il à été conçu.
          • [^] # Re: Partage de fichier "portable"

            Posté par . Évalué à 5.

            En effet, ce n'est pas parcequ'il est ancien qu'il est forcément mauvais... le ftp est mauvais parcequ'il n'est pas adapté aux besoins et aux risques modernes, tout comme le telnet et les gadgets genre rexec...

            On peut faire de bonnes soupes dans une vieille marmite tant que celle-ci n'est pas percée par la corrosion.
            • [^] # Re: Partage de fichier "portable"

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

              J'utilise ftp dans mon réseau local bien protégé pare mon parefeu. Avec konqueror ftp://login@machine est commode et performant.
              Pour me connecter à distance sur ma machine, ssh et sftp sont mes amis.

              ftp est aussi bien pratique pour télécharger un paquet ou une image iso sur un serveur public. il est inutile de crypter la communication dans ce cas.
              • [^] # Re: Partage de fichier "portable"

                Posté par . Évalué à 2.

                Tout à fait d'accord, pour des serveurs publics ou des environnements où la sécurité ne sont pas des paramètres importants, le ftp a encore de beaux jours devant lui, mais dès qu'il s'agit de partager des données dans un environnement où un minimum de sécurité est nécessaire, le ftp est hors course.

                Sinon, pour un lan, le NFS c'est pas mal non-plus... nfs:// ... ça marche aussi...
              • [^] # Re: Partage de fichier "portable"

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

                Avec konqueror ftp://login@machine est commode et performant.

                En même temps, si tu utilises Konqueror, fish est ton ami.
                fish://login@machine/ton/chemin/ est commode et performant.
            • [^] # Re: Partage de fichier "portable"

              Posté par . Évalué à 5.

              Pourtant telnet est bien pratique pour se connecter sur des systèmes à ressource limité : genrer bootloader, telephone portable, routeur (IRRC les freboox on un serveur telnet accessible seulement par les techniciens de free), ...

              Donc telnet n'est peut etre pas adapter au réseaux publique, mais s'il est limité au réseau privé il peut etre tres pratique...

              C'est pareil avec FTP...
              • [^] # Re: Partage de fichier "portable"

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

                SSH ?
                • [^] # Re: Partage de fichier "portable"

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

                  C'est effectivement beaucoup mieux, mais il y a encore beaucoup d'équipements qui ne le supportent pas (ou qui l'ont en option payante, comme chez Cisco par exemple, et évidemment "c'est trop cher" dira le chef).
                • [^] # Re: Partage de fichier "portable"

                  Posté par . Évalué à 5.

                  SSH reste un gouffre à ressources pour les (toutes) petites machines. Téléphones portables (Pas les smartphones, hein), vieux routeurs ADSL, et même pour configurer une simple carte PCI (Oui, ça existe).
                  D'ailleurs, dans ce dernier cas, ça permet de faire des cartes qui ne dépendent (presque) pas de l'OS (En fait, suffit de prendre, par exemple, un chipset ethernet bien supporté, pour faire l'interface avec la machine hôte) avec les drivers et quelques outils intégrés (Donc un développement plus facile, sur un système unique et connu, pas besoin de faire de tests sur X plateformes, et tout et tout).
                  Donc, Telnet, c'est quand même vachement bien dans certains cas.

                  Et faut pas oublier que s'il y a un telnet dans Windows, ben, il y manque quand même SSH par défaut.
      • [^] # Re: Partage de fichier "portable"

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

        > FTP fonctionne très bien partout non?

        non
    • [^] # Re: Partage de fichier "portable"

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

      Common Internet file system, anciennement server message block, remplacé sous Windows Vista par... SMBv2 !

      Tiens tiens, on retourne à un sigle qui ne contient plus « common »,serait-ce un hasard ?
    • [^] # Re: Partage de fichier "portable"

      Posté par . Évalué à 1.

      Euh,

      Il y a quand même SFU (client/serveur NFS/NIS sous Windows : http://www.microsoft.com/france/windows/sfu/default.mspx) qui ne marche pas si mal.

      AppleShare/AppleTalk sont disponible sous Linux.

      Voilà ma contribution à 2 balles.
    • [^] # Re: Partage de fichier "portable"

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

      SInon il existe les partages webdav il me semble qui permettent le partage de fichier a la samba.
  • # Chez les pros

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

    Pour moi Samba est un projet que j'adore. Pour la simple raison qu'en environnement pro il est hyper stable (je l'utilise pour 40 postes utilisateurs), qu'il remplace un contrôleur de domaine (sans GPO pour le moment, vivement la v4) facilement. Couplé à cups et ldap, c'est un régal.

    Il ne faut surtout pas que le projet s'arrête et je pense que ceux qui critiques l'acharnement des dev à vouloir faire communiquer Windows, autres avec Linux en réseau ne connaissent pas toute les contraintes en environnement pro. La plus facile à comprendre est l'utilisation au niveau utilisateur de logiciel qui fonctionne uniquement en environnement Windows... Oui il y a Qemu, Wine, VirtualBox... Mais je vous rappel que nous avons des utilisateurs qui ne veulent pas (et c'est normal) ce prendre la tête avec un montage informatique complexe et incompréhensible.

    Born to Kill EndUser !

    • [^] # Re: Chez les pros

      Posté par . Évalué à 5.

      Je suis d'accord avec toi.
      Par ailleurs, suite à cette dépêche, j'ai testé Samba 4 (alpha 4).

      Et bien... c'est vraiment prometteur ! On met en place un domaine encore plus rapidement (à mon goût) qu'avec un Windows 2003 !

      Plus besoin de s'embêter avec un OpenLDAP (mais si on veut, on peut à priori), une serveur LDAP est déjà intégré.

      Et quelle "joie" (oui, faut pas déconner non plus hein) quand le XP s'intègre du premier coup dans le domaine !

      Bref, un excellent boulot !

      Voiçi le howto que j'ai suivi pour ce test (sur une Etch): http://wiki.samba.org/index.php/Samba4/HOWTO
      • [^] # Re: Chez les pros

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

        L'intégration de LDAP c'est plus simple pour une installation "basic", mais l'intérêt d'un LDAP n'est pas de centraliser les données utilisateurs et d'authentification pour pouvoir les utiliser depuis d'autres applications ?

        Born to Kill EndUser !

  • # Samba,NFS,securite

    Posté par . Évalué à 0.

    Est ce que par défaut(sans gssapi/kerberos) SMB/samba chiffrent les mots de passe envoyés sur le réseau?

    sinon je trouve NFSv3 plus rapide que samba(sur un réseau gigabit ethernet),j'ai essaye NFSv4 mais il ne permettait pas de faire un chown(donc midnight commander ralle a chaque fois)
    sinon est il possible de chiffrer les mots de passe transmis par le réseau avec NFSv4 sans gssapi/kerberos? car si le serveur kerberos est compromis...toutes les clees prives sont compromises

    en gros quelle est la solution idéale,c'est a dire un réseau rapide et sécurise pour machines GNU/Linux uniquement(pour communiquer avec crimosoft windows il y'a toujours samba)
    • [^] # Re: Samba,NFS,securite

      Posté par . Évalué à 3.

      sinon je trouve NFSv3 plus rapide que samba(sur un réseau gigabit ethernet)
      CIFS est très bavard et extrêmement sensible à la latence.
    • [^] # Re: Samba,NFS,securite

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

      sinon est il possible de chiffrer les mots de passe transmis par le réseau avec NFSv4 sans gssapi/kerberos? car si le serveur kerberos est compromis...toutes les clees prives sont compromises

      Je ne sais pas, mais ça rejoint un problème que j'ai eu. Mettre en place un système de fichiers partagé entre deux machines GNU/Linux en environnement non maîtrisé (donc chiffrement indispensable, au moins des mots de passe), et bien, NFSv4, avec kerberos, quelle usine à gaz… j'ai essayé, mais pas réussi. Donc Samba. :-)
      • [^] # Re: Samba,NFS,securite

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

        Attention, je crois qu'une session samba se détourne... donc ce ne serait pas super sécurisé.

        NFSv4 a été conçu pour être transportés sur internet. Donc il n'y a pas de soucis à ouvrir un serveur NFSv4 sur un firewall (si l'implémentation est correcte, bein sur).
  • # Petit détail de français

    Posté par . Évalué à 2.

    Juste un petit détail : "suite à" n'est pas français, même si on le retrouve malheureusement trop souvent. Il faut dire "à la suite de".

    (La faute revient à ces opérateurs téléphoniques, fiers de vous annoncer "suite à votre dernier appel, il vous reste x euros de crédit"... Ainsi, c'est passé dans le langage courant.)
    • [^] # Re: Petit détail de français

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

      Sources ?
      • [^] # Re: Petit détail de français

        Posté par . Évalué à 3.

        En effet, ça serait bien des sources pour confirmer...

        J'ai trouvé ça, mais je ne sais pas ce que ça vaut : http://www.depeche.soquij.qc.ca/linguistique/ling20020121.ph(...)

        --- citation ---

        Chronique linguistique
        Impropriétés : «Suite à»

        L'expression «suite à» constitue une abréviation fautive des locutions suivantes, que l'on devrait toujours utiliser au long:

        1) Comme suite à ou pour faire suite à; ces locutions signifient à un correspondant que l'on reprend une question traitée précédemment, oralement ou par écrit, mais non nécessairement que l'on répond à sa lettre, ce qui s'exprime mieux par la locution en réponse à, tout simplement.

        2) À la suite de, qui comporte l'idée de conséquence. À la suite de ses efforts soutenus, il a pu achever son travail à la date promise.

        3) Par suite de, qui signifie elle aussi «en conséquence de».

Suivre le flux des commentaires

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