Un article inquiétant

• [^]Re: Un article inquiétant

  Posté par Aldoo (Jabber id, ) le 06/02/2005 à 10:08. (lien). Évalué à 4.

  Mouais, bof le coup du noyau linux basé sur le projet GNU ... m'enfin.
  
  Le principal reproche à faire à cet article, cepedant, cest qu'il ne dit pas vraiment pourquoi Samba devrait « trembler ». En effet, Samba se porte très bien actuellement sans les spécifications de Microsoft.
  
  Que Microsoft vende des données supplémentaires, je ne vois pas en quoi cela constitue une régression ... tant que les développeurs Samba ne les regardent pas.

• [^]Re: Un article inquiétant

  Posté par achil () le 06/02/2005 à 10:19. (lien). Évalué à 4.

  De toute maniere personnellement, j'ai toujours trouvé assez mauvais pour linux d'essayer de faire de la compatibilitée avec les produits de chez Microsoft.
  Que ce soit WMV, Office, NTFS, ou encore SMB, j'ai toujours trouvé le rendu moyen voir totalement imbuvable.
  
  Je serais plus d'avis à develloper des nouveaux standarts ouverts que d'aider l'utilisation des fermés, comme par exemple on rendant Windows compatible à un nouveau protocol réseau créé par la communautée et non l'inverse. (Un peu comme NetWare qui installe sont client pour les réseaux NetWare sur Windows... On aurait notre client pour le réseau Linux qui serait installé sur les machines clientes).
  
  Meme si le projet Samba est un projet de qualité, et qu'il ma perso souvent enlevé une belle épine du pied, cela ne m'empeche pas de penser qu'il n'est en rien nécessaire.

  • [^]Re: Un article inquiétant

    Posté par zeSixty4Douille () le 06/02/2005 à 10:41. (lien). Évalué à 1.

    moi aussi, ça me gêne de voir développer des "connector" pour continuer a utiliser des solutions Windows. Moi je ne les utilise pas, je préfère des solutions nouvelles, quitte a perdre un peu de temps.
    
    Une solution completement nouvelle a p-e moins de chances de s'imposer en solution de remplacement, mais a long terme, c'est plus sur et pour les nouveau besoins, ca change rien.
    
    Et ce type de risque n'existe pas.

  • [^]Re: Un article inquiétant

    Posté par Thomas Petazzoni (page perso, ) le 06/02/2005 à 10:46. (lien). Évalué à 6.

    Je ne suis pas un spécialiste, mais quelles sont les alternatives libres à Samba ne reposant pas sur le protocole SMB ? Je crois que NFS offre des fonctionnalités bien inférieures à celle que peut offrir Samba.
    
    Si ça se trouve, il y a même des endroits où il n'y a que des machines GNU/Linux et où Samba est utilisé.

    • [^]Re: Un article inquiétant

      Posté par Éric (Jabber id, page perso, ) le 06/02/2005 à 11:56. (lien). Évalué à 3.

      Pour NFS la dernière version 4 doit corriger pas mal de choses.
      Sinon on a plein de FS par réseau implémentés sous Linux. Le problème est surtout que ce n'est pas dispo sous Windows, donc peu répandu.

  • [^]Re: Un article inquiétant

    Posté par Djouxxx () le 06/02/2005 à 10:57. (lien). Évalué à 6.

    C'est vrai que pour un utilisateur linux (ou plutôt du libre en général) convaincu les projets que tu cites peuvent sembler n'avoir que peu d'intérêts. Mais en réalité, ces projets permettent de créer le lien avec le monde de l'entreprise où l'informatique n'est qu'un outil.Cela permet d'intégrer linux petit à petit dans ces domaines. Après il est facile d'étendre la place de linux(serveur web, proxy web peuvent venir rapidement). Donc moi je vois ces projets comme des projets accrocheurs permettant à linux de s'implanter en entreprise ou chez meussieur tout le monde et lui permettre de faire la preuve de ses qualités.
    Il faut bien se rendre compte que linux n'est qu'un outsider pour l'instant et c'est donc à lui de faire le plus d'efforts de compatibilité. Après lorsque une certaine masse critique d'utilisateur sera atteinte, il deviendra possible "d'imposer" directement des standards ouverts.
    
    Djouxxx

    • [^]Re: Un article inquiétant

      Posté par Matthieu C () le 06/02/2005 à 11:23. (lien). Évalué à 2.

      Au fait windows peut supporter le NFS en utilisant service for unix...
      Bon apres je sais pas a quel point sont pousse le remapping des users, et surtout il faut faire confiance au client NFS...

    • [^]Re: Un article inquiétant

      Posté par achil () le 06/02/2005 à 11:59. (lien). Évalué à 3.

      Le problème est que dans ce sens de dévellopement, Microsoft à toujours une avance technologique est au final on tombe fasse à des discourts du type:
      "Linux c'est moins cher mais c'est moins bien que 2003 Server car moi mon réseau Windows il marche parfaitement et avec toutes les fonctionnalitées".
      Ce phénomène sera même fortement agrandi si en plus Microsoft publie de moins en moins de spécificitée. Pour moi un Samba qui tourne aussi bien que le dernier serveur windows est une utopie, il leur est si facile de nous brouiller le travail pour comprendre leur système...
      
      Pour moi Samba devrait justre etre utile afin de passer d'un reseau Microsoft à un réseau géré par un systeme Libre comme OpenAFS ou le truc de Novell (Cf commentaire d'en dessous).
      
      C'est comme si aujourd'hui tout le monde écoutaient ces musiques au format OGG, les utilisateurs lambdas ne vérraient aucune différence entre utiliser Windows ou Linux car ca marcherai aussi bien des deux cotés. Or aujourd'hui je ne cesse de voir des: Oué mais linux c'est nul je peus pas lire mes wma...
      Chez moi c'est clair: Tout est au formats Libre, et je demande au maximum à mes amis d'utiliser ceux ci.
      
      Tout ca c'est le meme combat on tourne en rond, maintenant il faut pousser les utilisateurs de windows à utiliser les formats ouverts.
      
      Conclusions: Samba est la pour créer un lien TEMPORAIRE entre les réseaux Microsoft et Linux afin de permettre le passage à un système ou le protocol est libre. Tout ce que demande l'utilisateur lambda c'est des fonctionnalitées et le prix. Pour moi c'est clair en suivant Microsoft et son protocol on va dans le mur.

  • [^]Re: Un article inquiétant

    Posté par Al Brow () le 06/02/2005 à 11:12. (lien). Évalué à 1.

    Désolé c'est déjà fait depuis une décennie : OpenAFS.
    
    Sans compter que netware qui est de facto libre. J'attends avec impatience l'intégration de iFolder dans gnome.

    • [^]Re: Alternatives à smbfs

      Posté par Matthieu Lagouge (Jabber id, page perso, ) le 06/02/2005 à 11:53. (lien). Évalué à 7.

      Moi, ce qui m'intéresse, c'est moins de savoir que samba a été créé pour "suivre" microsoft que de connaitre les avantages des solutions proposées.
      Qu'apportent OpenAFS ou NetWare de plus que samba?
      
      Et pour revenir à qui impose quoi, il me semble que microsoft va bien devoir supporter le format oasis pour MS Office, c'est déjà une première bataille de gagnée! Et avec la montée progressive de firefox, il faudra bien qu'ils tiennent compte des standards du web (enfin, là j'espère plus que je ne suis sûr...). Tôt ou tard, on finira bien par contraindre microsoft à rentrer dans le rang, ne serait-ce que pour satisfaire ses utilisateurs!

  • [^]Re: Un article inquiétant

    Posté par Xavier (page perso, ) le 06/02/2005 à 13:07. (lien). Évalué à 1.

    bonjour,
    
    
    mais alors pour partager des données entre plusieurs machine linux on utilise quoi?
    
    J'ai lu dans un journal de ne pas utiliser NFS, c'est pas bien et c'est bugué.
    On disait d'utiliser SMB... Existe t'il un système propre à linux pour l'échange de fichier?
    
    Par ce que ça me plairait bien de le connaître pour l'utiliser et le faire connaître...
    
    Merci...

    --
    Good judgement comes from experience and experience comes from bad judgement |
    Faisez la mouche pas la guêpe...

    • [^]Re: Un article inquiétant

      Posté par Matthieu C () le 06/02/2005 à 13:24. (lien). Évalué à 4.

      NFS est en majorite utilise pour le partage de donne dans le monde unix et donc en particulier linux. L'inconvenient de NFS c'est qu'il n'a pas ete concu avec la securite comme objectif, donc c'est a reserver sur un reseau local entre des machines pour lequel on a confiance...
      
      J'ai lu dans un journal de ne pas utiliser NFS, c'est pas bien et c'est bugué.
      T'as les arguments qui vont avec...

      • [+] [^]Re: Un article inquiétant

        Posté par Xavier (page perso, ) le 06/02/2005 à 14:03. (lien). Évalué à -1.

        Pour les arguments, je ne m'en souveneais plus et en aucun cas je n'ai pris parti. Mais, il me semble qu'il s'agit justement de cette histoire de sécurité.
        
        Le pasbienc'estbugué était pour justement faire réagir ;)

        --
        Good judgement comes from experience and experience comes from bad judgement |
        Faisez la mouche pas la guêpe...

    • [^]Re: Un article inquiétant

      Posté par Sytoka Modon (page perso, ) le 06/02/2005 à 13:32. (lien). Évalué à 5.

      Personnellement, j'utilse nfs en réseau local et j'ai très peu de soucis. Surtout, il se marie très bien avec l'automounter autofs. Bien sur, il ne faut pas exporter à tord et à travers mais aux seuls postes dont on a confiance.
      
      Sinon, tu peux aussi faire du sshfs (ou lufs). C'est au même niveau que smbfs avec les mêmes inconvénients : c'est en mode utilisateur et non en mode machine. Si tu as 10 utilisateurs sur la même machine, il y aura autant de point de montage, alors qu'avec nfs+autofs, tu mutualises les points de montage (et en plus ca demonte tout seul).
      
      A un niveau plus bas, tu peux aussi partager des blocs de disques avec drdb ou endb. Enfin, il s'agit plus d'exporter vers un serveur de l'espace disque qui ne sert pas en local afin de faire du RAID réseau.
      
      - drdb http://www.drbd.org/
      - endb http://www.it.uc3m.es/~ptb/nbd/
      
      - sshfs http://shfs.sourceforge.net/
      - lufs http://lufs.sourceforge.net/lufs/
      
      Enfin, certains tunnelisent nfs dans ssh mais je n'ai pas encore essayé.

      • [^]Re: Un article inquiétant

        Posté par Arachne (page perso, ) le 06/02/2005 à 15:14. (lien). Évalué à 3.

        On a encore de gros problèmes de stabilité avec NFS sous Linux. Et on peut difficilement se permettre de devoir rebooter un serveur en prod à cause d'un ènième crash du FS... Mais bon c'est un peu plus utilisable que SHFS, qui me pète au nez tous les jours.
        
        D'autre part en terme de performances avec NFS, même avec du gros tuning, on est toujours déçu sur certaines config, sans avoir d'explications logiques (machines puissantes, réseau Gb sans trop de loss...). Et les performances de Samba ne sont pas à la hauteur non plus...
        
        Concernant DRBD, l'idée est bonne, la pratique moins. En effet le FS n'est accessible en écriture que par un seul des nodes, ce qui limite vachement l'intérêt. ENBD je n'ai pas testé.
        
        Bref les FS réseau sous Linux c'est pas le pied.
        
        Tiens j'en profite pour poser une question qui me trotte dans la tete depuis pas mal de temps : Dans une plateforme d'hébergement web assez costaude, soient un load balancer, des frontaux, des serveurs applicatifs, et des serveurs de bases de données. On peut sans problème dupliquer les reverse proxy en frontal, ainsi que les serveurs de BDD, qui sont équipés de mécanismes de réplication performants. Le problème se situe au niveau des serveurs applicatifs.
        
        Certaines applications (PHP par exemple) peuvent générer des pages à la volée (comme sur DLFP). Ces pages, une fois créées, ne doivent pas l'être de nouveau sur les jumeaux du serveur. Bien sûr on pourrait coder les sites en fonction, mais on souhaite être totalement indépendant de la plateforme. Il faut donc partager le système de fichiers afin de synchroniser ces données. Pour l'instant on monte un NFS à partir d'une autre machine, mais il faut bien avouer que c'est cracra et que c'est pas très "haute disponibilité". Je cherche une solution du genre DRBD, avec écriture sur tous les nodes. Quelqu'un aurait une idée ? Je ne dois quand meme pas être le seul confronté à ces problèmes...

        • [^]Re: Un article inquiétant

          Posté par Volnai () le 06/02/2005 à 15:29. (lien). Évalué à 3.

          Je cherche une solution du genre DRBD, avec écriture sur tous les nodes
          
          Une baie de disque avec un attachement sur chaque serveur (tu es limité par le nombre de connecteur scsi, mais bon), plus un filesystem type opengfs ne repondrais pas à tes besoins ? Ou sinon un vrai SAN, mais ca explose probablement ton budget (ou alors t'as de la chance).

        • [^]Re: Un article inquiétant

          Posté par Sytoka Modon (page perso, ) le 06/02/2005 à 16:22. (lien). Évalué à 2.

          Je te suis completement. Je recherche moi aussi un système de fichier distribué redondant (RAID) avec écriture sur tous les noeuds. Il y a bien des tentatives positives (type intermezzo) mais ca ne m'a pas encore impressionné au point de mettre NFS et Samba au rencard. Surtout que ces deux derniers progressent aussi ;-)

  • [^]Re: Un article inquiétant

    Posté par reno () le 06/02/2005 à 13:22. (lien). Évalué à 2.

    Pas tres realiste ce que tu dis, la réalité est que Windows est là et que si tu veux ajouter du Linux dans un environement Windows, tu dois t'intégrer dans l'existant en minimisant le changement.
    
    D'ou les problemes de compatibilité..

    • [^]Re: Un article inquiétant

      Posté par Sytoka Modon (page perso, ) le 06/02/2005 à 13:40. (lien). Évalué à 1.

      Je suis d'accord. Lorsque tu te retrouves administrateur d'un réseau, c'est pas toi qui décides de qui utilise quoi. Tu es là au service des utilisateurs.
      
      Alors, tu commences avec un petit Linux dans un coin, puis tu transformes l'essai en contôleur de domaine. Tu ajoutes un serveur web, un proxy web, un dns...
      
      Après quelques années, certains te demandent Linux sur leur portable. Là, c'est presque gagné, mais il ne faut pas décevoir.

Ben c'est bien...

• [^]Re: Ben c'est bien...

  Posté par Sasuke () le 06/02/2005 à 12:49. (lien). Évalué à 3.

  En tout cas pour une nouvelle, c'est une bonne nouvelle. Combien d'entreprise achètent Windows 2003 justement pour active directory et ses déléguation de domaine ? Ca fera un argument réfutable en plus si la question de la migration se pose :)

Quelles solution ?

• [^]Re: Quelles solution ?

  Posté par Sytoka Modon (page perso, ) le 06/02/2005 à 16:37. (lien). Évalué à 3.

  D'abord, il ne faut pas rêver sur les profils itinérants... Plus ils sont petits, mieux c'est. Il est donc utile de connecter un lecteur réseau au démarrage de la session et de rediriger avec une clef de registre qui va bien le dossier utilisateur vers ce lecteur réseau. Ca c'était pour les postes Windows.
  
  Pour les postes UNIX, je préfère pour le moment le couple NFS + AUTOFS. Au niveau de l'authentification, deux solutions sont possibles : un annuaire LDAP ou un bête annuaire NIS (peu sécurisé mais très facile à mettre en place). Pour peu de poste, la solution NIS est très performante.
  
  Après, on fait une table de correspondance entre les partages NFS et les partages Samba.
  
  Pour l'impression, je trouve que le server LPRNG ne plante jamais, ce qui n'était pas de mon ancienne version de CUPS + Samba. Je configure les postes clients sous Windows pour qu'ils impriment en mode LPR.
  
  Ce qu'il me manque, c'est une authentification propre sur un portable sous Linux lorsque celui-ci n'est pas connecté au réseau local. Un poste Windows retient les derniers login/passwd je sais pas où, mais les personnes peuvent se connecter même si le poste est coupé du réseau (ou que le contrôleur de domaine est planté).

  • [^]Re: Quelles solution ?

    Posté par Michel Galle () le 06/02/2005 à 20:57. (lien). Évalué à 1.

    nscd , le name service cache daemon
    
    cela ne te permet pas de garder en cache des logon/password même si la machine est déconnectée ?

    • [^]Re: Quelles solution ?

      Posté par Sytoka Modon (page perso, ) le 07/02/2005 à 09:25. (lien). Évalué à 1.

      Exact, j'avais regardé de ce coté mais il perdait les informations lors d'un reboot. /A priori/, on doit pouvoir le configurer pour qu'il ne perde pas les infos au reboot.
      
      Par contre, en faisant une recherche rapide sur le net, il a tendance après à ne plus faire les requêtes donc à ne pas se mettre à jour. Il faut donc purger les caches mais seulement lorsque le PC est connecté sur le réseau local...
      
      Bon, je vais regarder ca de plus près.

• [^]Re: Quelles solution ?

  Posté par fenril () le 06/02/2005 à 16:52. (lien). Évalué à 6.

  C'est bien "profils itinérants"
  
  Avec ceci dans ton smb.conf, ça devrait passer comme une lettre à la poste.
  
  
  logon path = \\%L\%U\.winprofile
  logon home = \\%L\%U
  logon drive = H:
  
  
  Inspire toi de /usr/share/doc/samba-doc-*/examples/*
  
  Je t'invite aussi à te pencher sur:
  
  -DNS (bind)
  -DHCP (dhcp-server)
  -CUPS (cups)
  -LDAP (openldap)
  -KERBEROS (krb5)
  -NTP (ntp)
  
  Installe les dans cet ordre. Migre tes comptes dans un annuaire LDAP. peaufine s'il le faut avec PHPLdapAdmin, Installe samba en dernier avec ceci dans le .conf:
  
  Mon domaine a pour nom shanga.net, adapte
  
  add user script = /usr/share/samba/scripts/smbldap-useradd.pl '%u'
  delete user script = /usr/share/samba/scripts/smbldap-userdel.pl '%u'
  add user to group script = /usr/share/samba/scripts/smbldap-groupmod.pl -m '%u'
  delete user from group script = /usr/share/samba/scripts/smbldap-groupmod.pl -x '%u' '%g'
  set primary group script = /usr/share/samba/scripts/smbldap-usermod.pl -g '%g' '%u'
  add group script = /usr/share/samba/scripts/smbldap-groupadd.pl '%g' && /usr/share/samba/scripts/smbldap-groupshow.pl %g|awk '/^gidNumber:/ {print $2}'
  delete group script = /usr/share/samba/scripts/smbldap-userdel.pl '%g'
  add machine script = /usr/share/samba/scripts/smbldap-useradd.pl -w -d /dev/null -g machines -c 'Machine Account' -s /bin/false %u
  idmap backend = ldap:ldap://ldap.shanga.net
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  ldap admin dn = cn=Manager,dc=shanga,dc=net
  ldap ssl = start_tls
  ldap suffix = dc=shanga,dc=net
  ldap idmap suffix = ou=Idmap
  
  ldap machine suffix = ou=Hosts
  ldap user suffix = ou=People
  ldap group suffix = ou=Group
  
  ;ou ceci:
  ;ldap machine suffix = cn=Computers
  ;ldap user suffix = cn=Users
  ;ldap group suffix = cn=Groups
  
  
  Voilà, Il y a dix tonnes de docs à lire, auquelles je ne saurais me substituer en un post.
  Bonne chance
  PS: Pense à la clé rndc pour DNS/DHCP
  PPS: Le piège pour dhcpd.conf c'est:
  
  
  subnet 192.168.2.0 netmask 255.255.255.0 {
  option ....
  ddns-updates on;
  ddns-domainname "shanga.net";
  ddns-rev-domainname "2.168.192.in-addr.arpa";
  allow client-updates;
  }
  ddns-update-style interim; <----- à l'extérieur du subnet

• [^]Re: Quelles solution ?

  Posté par Florent Zara (Jabber id, page perso, ) le 06/02/2005 à 21:26. (lien). Évalué à 1.

  Regardes du côté de la distribution SME Server. Elle couvre beacoup de besoins que tu exprimes, et c'est relativement simple d'utilisation.
  
  plus d'infos sur le site: http://www.contribs.org(...)

SambaEdu