J'abonde dans ton sense (je "plussois"), il y a trop de traduction au mot à mot.
Certaines francisations sont horribles, la carte des périphériques est une mauvaise traduction de device mapper, le terme anglais serait device map.
Je ne pense pas que cartographieur soit une traduction plus appropriée, peut être que le gestionnaire des associations entre périphériques est plus juste.
Le fait est que l'anglais est malheureusement bien mieux adapté pour transmettre un concept en un nombre limité de mots.
Sinon en lisant les commentaires je crois comprendre que la base ldap interne de samba4 pourrait être utilisé par des tiers ce qui pourrait être une option si j'arrive à intégrer les schémas dont j'ai besoin avec les restrictions d'un AD.
Samba (comme toute autre implémentation de l'AD) propose un serveur LDAP qui peut être interroger comme n'importe quel autre serveur LDAP, le protocole LDAP est un des moyen d'interroger la base interne de Samba (les autres moyens sont les "bindings" pyhon, ou bien les outils ldbsearch/ldbadd/ldbmodify)
Ça par contre, encore une fois sauf mécompréhension de ma part sur l'utilité de la chose, c'est beaucoup plus bloquant. Non?
Oui c'est plus gênant, si tu as une solution pure Samba 4 tu peux t'en sortir avec rsync + csync mais dans une domaine mixte windows/samba c'est un assez gros problème.
On est en train de résoudre ce problème en implémentant les protocoles nécessaires.
Bon c'est pas forcement une excuse mais j'habite depuis quelques temps à l'étranger donc non dépôt m'est pas revenu à l'esprit, mais merci pour la traduction. Le "sondage" me semble plus litigieux.
Quand tu dis que openLDAP est le standard, j'ai un peu du mal. Pour moi le standard c'est LDAP ensuite si tu utilise le logiciel A, B ou C qui implémente ce standard ça doit être transparent pour toi.
"Tant qu'a utiliser Samba 3 en DC avec le backend OpenLDAP autant en faire de même pour Apache, Bind, Dhcp, la connexion VPN, ftp, la messagerie… "
Qu'est ce qui t'empêche de le faire avec Samba 4?
Dans mon précédant travail j'utilisais Samba 4 et j'avais Apache, OpenVPN, Cyrus IMAP et Postfix qui utilisaient le LDAP de Samba 4 et sans problèmes.
Pour ceux qui utilisent Samba 3 + LDAP il y a un outil de migration: samba-tool domain classicupgrade, j'avoue que je ne sais pas si on migre juste les utilisateurs et les mots de passes ou si on fait plus et si oui jusqu'à quel point.
Il y a surement plus de chose que l'on pourrait faire, mais souvent tout commence quand un utilisateur tente d'utiliser quelque chose et que ça marche pas comme il veut et qu'il en parle sur la liste samba-technical et qu'il essaye de trouver une réponse lui même.
En gros on est que des êtres humains, si on voit quelqu'un de motivé on va avoir plus tendance à l'aider que quelqu'un qui dit juste oh c'est nul ça marche pas et puis on autre LDAP il déchire.
"il va falloir remettre en question des années de centralisation et de travail pour faire communiquer les différentes applications parce que les dev ont décidé d'intégrer leur propre annuaire dans Samba 4. Microsoft est souvent critiqué pour son manque d'ouverture mais je pense que sur le coups Samba 4 est bien placé."
Ah les salauds de développeurs Samba, on pas attendu assez la version 4 ils auraient du attendre d'avoir un support complet openLDAP avant de faire une version stable. Forcement si il n'y a pas d'intégration avec OL c'est la faute du projet Samba, pas la faute du projet openLDAP.
La vérité c'est que quand on a commencé à travailler sur la partie AD il nous fallait un truc pour faire du prototypage rapide et l'utilisation d'un projet externe est pas bien adapté à ce besoin. Au fur et à mesure que l'on a avancé, on s'est rendu compte que notre solution était pas si mal et il n'y avait pas trop de proposition de la part de openLDAP pour nous aider à faire d'OL un citoyen de première classe. Alors à ressources limités on a choisit notre implémentation.
Quand il s'est agit de travailler sur le serveur DNS, on s'est tourné vers BIND mais c'est pas simple de bosser avec ce projet (un indice: tente de soumettre un patch et fait moi signe dans 3 ou 4 ans quand ils vont daigner avoir un coup d'oeil à ton patch …), alors on a regarder d'autres projets et quand on a contacté ceux qui étaient en vie et non toxique ils nous on dit: "le support pour DDNS à la sauce TSIG-GSS, et puis une gestion des ACL plus fine ça nous intéresse pas", alors ben oui on a fait notre propre petit serveur DNS.
"J'ai déjà pensé à ça mais je ne suis pas dev et je ne connais pas toute les subtilités du protocole SMB."
Quand j'ai commencé à bosser sur Samba je connaissais presque rien à LDAP, rien à Kerberos et je connais toujours bien peu de SMB.
Mais je me suis mis sur les choses qui me posait des problèmes à ce moment là et puis j'ai posé des questions et j'ai pris des traces réseau pour mieux comprendre.
J'ai fait pas mal de patches pour Wireshark pour mieux comprendre ce qui se passait au niveau réseau et quels étaient mes problèmes.
Combien même tu n'es pas expert, il y a toujours quelque chose à faire: de la documentation, de l'aide sur le forum et les listes, aider à mieux caractériser les bugs, faire des essais de migration de configuration, …
Il y a sûrement peu que tu puisses faire pour accélérer l'utilisation de OL comme base de stockage pour Samba, mais à l'opposé il y a sûrement beaucoup de chose que tu peux faire pour que la migration vers le serveur LDAP de Samba soit moins misérable ou alors que l'ajout de services à ce LDAP soit plus simple.
Le retour que l'on a c'est que ça se passe bien sauf quand on essaye de faire un migration directement depuis Windows 2000.
Car cette version est truffées de drôles de comportements qui ont été corrigés par Microsoft dans Windows 2003.
Aussi on recommande à ceux qui veulent migrer et qui sont encore avec 2000 de passer par une version intermédiaire de Windows (ie. 2003, 2008, ou bien même 2012) de changer le niveau du domaine pour 2003 et aussi pour la niveau de la forêt.
Ensuite joindre un contrôleur Samba.
On recommande aussi de faire un test à blanc avec au moins une copie d'un des contrôleurs dans un réseau complètement isolé du réseau réel (afin que les contrôleurs de test ne se mettent pas à répliquer avec ceux en production …) et faire tourner la chose pendant quelques jours avec quelques clients Windows pour être sûr.
Au cas où il y aurait des problèmes => samba-technical@samba.org ou #samba-technical sur irc.freenode.org
Pour voir le niveau d'intégration de la réplication entre contrôleurs Windows et Samba je conseille de regarder cette vidéo (en anglais): http://samba.org/tridge/Samba4Demo/s4demo4.ogv
Ah bon ?
Je pense que c'est moi qui a rédigé la nouvelle pour 4.0 et je pense pas avoir dit ça.
4.0 n'avait pas de support officiel pour plusieurs contrôleurs entre autre parce qu'on pensait que le retour d'expérience n'était pas suffisant et puis aussi parce que le support multi-domaine n'existait pas (il existe toujours pas) et que la réplication de sysvol (toujours pas aussi).
On veut pour l'instant éviter des déconvenues aux admins qui pense que c'est un remplacement à 100%
Symas (l'entreprise qui est derrière la majeure partie du développement de openLDAP) a maintenant deux développeurs qui travaillent à faire en sorte que Samba puisse de nouveau utiliser openLDAP comme stockage pour sa base de donnée SAMDB.
La tâche n'est pas simple pour plusieurs raisons:
Quand Samba utilise OL comme stockage ("storage backend"), la bibliothèque LDB va émettre des commandes LDAP pour lire et écrire dans OL, mais pour l'instant OL ne supporte pas les transactions sur les requêtes LDAP, toutes les requêtes en écriture sont définitives (pas de retour arrière ou "rollback"); c'est un gros problème car les transactions sont fréquemment utilisées en interne par Samba en particulier pour le protocole DRS (celui qui gère la réplication de la base sur tous les contrôleurs de domaines).
Il va falloir introduire la notion de transaction sur lDAP (en fait je crois que c'est déjà en cours chez OL) et l'utiliser.
Le développement de Samba utilise des notions d'intégration continue qui fait que chacun des commits dans le repository passe au travers ~1000 tests unitaires et de bout en bout où plusieurs variantes de Samba sont démarrées et testées (serveur de fichier, AD niveau 2003, AD niveau 2008, 2 contrôleurs, …) il va donc falloir intégrer OL dans la mécanique pour qu'une série de tests soient fait avec OL comme base de stockage.
De nombreux tests de bout en bout échouent pour l'instant quand on utilise OL comme stockage, il va falloir résoudre ces problèmes.
Une fois ceci fait, OL pourra être utilisé comme base de stockage, mais attention il faudra encore à ce moment oublier l'idée d'envoyer des requêtes directement à OL, OL sera privatisé pour Samba et seul le serveur LDAP de Samba sera accessible.
Je sais que openLDAP va travailler aussi sur un "overlay" afin que OL soit de nouveau joignable sur les port habituels mais je pense que c'est pas mal de boulot donc il va falloir attendre.
Pour finir il faudra aussi oublier l'idée que l'on puisse mettre à jour une installation OL existante pour lui rajouter la personnalité AD, pour l'instant la commande "provision" de Samba part d'une base vierge. Partir d'une base existante va représenter à lui même un défi compliqué à résoudre et qui dans les cas compliqués ne pourra pas l'être car AD insiste pour avoir sa propre organisation de l'annuaire et son propre schéma qui ont des chances d'être incompatibles avec ceux de la base existante.
Que signifie synchroniser la base interne ?
Quand on demande a 10 personnes différentes on a dix réponses différentes …
Il existe déjà des solutions en utilisant le contrôle dirsync (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/ms677626%28v=vs.85%29.aspx), qui permette de faire du polling (avis aux maîtres Capelo pour la traduction) et de recevoir que le delta des informations modifiées.
Ca permet de synchroniser les deux annuaires, mais il y a toujours une latence.
Dans le repository (avis aux maîtres Capelo pour la traduction) il ya un petit programme en python qui en fait la démonstration cf.
source4/scripting/devel/demodirsync.py.
Pour d'autre synchroniser signifie, avoir une base commune openLDAP/Samba AD et sous entendu utiliser openLDAP comme serveur LDAP pour Samba.
C'est pas possible et c'est pas demain la veille que ça va changer.
Que peut-on faire au niveau du DHCP? D'après ce que je crois savoir, ce sont les machines qui reçoivent leur adresse qui, par >défaut, mettent à jour leurs enregistrements dans le DNS, exact? Personnellement, je considère que BIND + DHCP c'est du (trop) lourd >et je leur préfère DNSmasq, un excellent combiné DHCP + DNS dont le principal avantage est de mettre à jour le DNS sur base du DHCP. Y >a-t'il des pistes à suivre pour Samba 4?
Pour l'instant il y a deux serveurs DNS possible pour Samba 4 et je ne pense pas que DNSmasq soit à l'ordre du jour, avec ISC DHCP est capable de mettre à jour les enregistrements DNS pour les machines à qui il attribue une adresse. Malheureusement ISC utilise un mécanisme de clé partagée pour faire ça et pour l'instant ça ne marche qu'avec Bind (et encore pas sûr que ça marche avec tous les backends), j'avais fait un article sur mon blog il y a quelques temps de cela: http://is.gd/Ox78Iv.
Je pense qu'on y pense mais pour l'instant rien n'est fait.
Peut-on envisager que le service Kerberos intégré dans Samba soit modularisé comme mit-krb5? Ou bien que les améliorations et >personnalisations apportées à ce service soit reprises dans le code de mit-krb5?
La réponse est oui, et c'est même en cours puisque RedHat fournit par défaut MIT comme implementation Kerberos donc pour pouvoir offrir un paquet Samba 4.0 AD pour RHEL il faut qu'il utilise MIT Kerberos comme KDC.
Mais la question c'est quel est exactement le besoin ?
(Je présume que c'est PAC le facteur primordial à >l'origine de l'intégration de Kerberos dans Samba 4?)
Pas vraiment, c'est juste les gens d'heimdal étaient plus ouvert aux changements nécessaire du fait des besoins pour avoir un KDC compatible AD.
Je poserais aussi volontiers la version bis de la question ci-dessus à propos de LDAP.
Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?, la raison c'est qu'il faudrait ré-écrire plein de modules pour Openldap et il se pose la question de maintient de l'intégrité avec les autres serveurs (Netlogon, LSA, …).
L'autre option c'est d'utiliser Openldap comme backend de stockage, on a essayé mais on ne supporte plus parce que cette solution ne marche pas bien:
- Afin que ça fonctionne il faut que l'instance Openldap soit "privatisé" pour Samba sinon il peut se passer de drôles de choses si quelqu'un fait des modifications directement via LDAP en by-passant les modules spécifiques AD.
- Il faut que Samba parte d'une nouvelle installation, pas moyen de faire une mise à jour d'une installation existante car les schemas AD sont partiellement incompatibles.
Pour les besoins d'un AD, il faut que le serveur supporte les mises à jours dynamiques signées (principalement TSIG) et un système d'ACL assez puissant et puis qu'ils permette de faire du multi-master.
Ce qui limite pas mal le choix, ensuite idéalement il devrait pouvoir utiliser les partitions de l'AD ce qui permet de partager avec d'autres implementations (facilite la migration d'un système à l'autre …).
Pour finir je sais que la personne qui s'est occupé du serveur de DNS a pris contact avec les développeurs de dnsmasq mais ceux-ci n'étaient pas trop intéressés, alors certes c'est open-source donc tu peux forker le code et tout le toutim mais en réalité c'est forcement une super idée.
En plus il est possible que l'architecture de ce projet ne soit pas tip top (selon tes critères).
Au final le serveur interne de Samba a été développé en peu de temps (max 2 mois avec principalement un seul développeur) avec très peu de code à proprement parlé car il y a eu réutilisation de beaucoup de "framework" qui avait été développé pour les autres serveurs de samba.
One last thing, comme disait l'autre, Samba reste un projet opensource où certains contributeurs le font principalement sur leur temps libre parce que c'est "fun", c'est le cas du serveur DNS qui a été fait principalement sur le temps libre de Kai Blin parce que ça lui plaisait de faire ça. Il est pas sûr qu'il aurait utilisé ce temps à faire autre chose de plus "utile" si il n'avait pas passé du temps sur ça.
Alors je pense que la version 4.0 est aussi conseillée que la dernière version de la branche 3.6 surtout en ce qui concerne la partie serveur de fichier car:
- Il y a eu peu de modification de code dans cette partie
- Chaque commit doit passer une batterie de 1500 tests de bout en bout avant pouvoir être réellement intégré au "master tree git"
- Il a été testé en condition réelle pendant les betas et les release candidate
Après si tu dois faire un choix entre la version 3.6.x où les mises à jours de sécurité sont assurées par la distro ou bien avoir à suivre les différentes alertes de sécurités Samba et faire les mises à jours soit même, je te laisse prendre la conclusion qui va bien en terme de facilité de la chose.
Mais à niveau de support équivalent, il n'y a aucune bonne raison pour rester à la version 3.6.x
Le rôle d'une entreprise est multiple et pas uniquement de faire de l'argent. L'entreprise peut être là pour répondre à des besoins, >faire progresser l'offre, assurer un travail à ses salariés. Même pour un libéral, il peut être acceptable de réduire les bénéfices >reversé aux actionnaires, a une récompense équivalente à la prise de risque qui a permis l'aventure sociale de l'entreprise.
Je ne suis pas d'accord le but premier d'une entreprise à but lucratif c'est de faire de l'argent, pas forcement à n'importe quel prix et pas forcement pour les actionnaires mais cela reste quand même le but principal.
Bien qu'il manque encore quelques fonctionnalités essentielles à Samba 4 (essentiellement la prise en charge complète de la >réplication),
Le lien relatif à cette remarque date de 2005 …, au sein d'un AD il y a deux type de réplications qui ont lieu:
Réplication de l'annuaire
Réplication des système de fichiers
La première réplication est implementée depuis 2009 et fonctionne relativement bien, la seconde est toujours en cours de développement et est indispensable pour un bon fonctionnement de Samba dans un environnement mixte (Samba + Windows AD)
Samba 4 inclut un serveur DNS. Il est toutefois possible d'utiliser un serveur DNS externe.
[…]
Samba 4 comprend un serveur LDAPv3 développé pour l'occasion, dans le respect des standards, bien sûr.
Je ne comprends pas, pourquoi réinventer la roue ? Voilà sans doute ce qui a retardé Samba 4.
Quand on ne sait pas le mieux est de se taire de peur de dire des bêtises !
Les raisons qui ont poussé à la création d'un serveur DNS internes sont :
- Complexité de configuration de Bind 9.x, avec une liste de versions compatibles bien précises, incompatibilité des configuration entre bind 9.7, 9.8 et 9.9
- Automatisation des tests de bout en bout sans dépendance avec bind (car tous les développeurs n'ont pas forcement la bonne version de bind installée.
- Réduction de la mémoire utilisée pour les systèmes types embarqués (beagle board, …)
Les raisons qui ont poussé à la création du serveur LDAP sont:
Absence de support pour les transactions LDAP (indispensable pour la réplication entre 2 contrôleurs)
Très fort couplage entre les différents composants (serveur LDAP, serveur Kerberos, gestionnaire des protocoles Netlogon, LSA, …) qui implique qu'un changement réalisé par via un protocole (ie. LDAP) soit instantanément visible dans les autres protocoles (Kerberos, Netlogon)
Schema AD spécifique et incompatible pour certain OID
Les raisons du "retard" sont la complexité des protocoles, si il est facile de faire fonctionner une authentification type AD (la démo a été faite en 2005) il en est moins aisé de faire un serveur qui est suffisamment stable pour que les utilisateurs soient d'accord pour faire fonctionner le cœur du système d'autorisation et d'authentification sur une solution alternative.
Une raison du "retard" est aussi "où sont vos patches", il y a toujours beaucoup de personnes pour critiquer le retard mais assez peu pour proposer des patches pour corriger les bugs ou bien implementer de nouvelles fonctionnalités.
À la base, Samba 4 était une réécriture complète, y compris de la partie partage de fichier, finalement la partie partage de fichier a >été reprise de samba 3 mais ça montre bien que le projet se voulait fort différent.
Si une nouvelle architecture (NTVFS) étaient bien prévu pour la version 4.0 elle n'a pas été retenue comme implemantation par défaut car entre temps beaucoup de changements introduit par samba4 ont été back-portés au cours des différentes versions 3.x.
Ce fut le cas de la librairie talloc (http://talloc.samba.org) (pour la gestion hiérarchique de la mémoire), de la génération de code pour les protocoles (CIFS, NETLOGON, LSA, …) du stockage des ACLs NT 100% fidèles à ce qui est spécifié du coté client.
De ce fait les avantages relatifs aux changements d'implementation (S3FS -> NTVFS) étaient moins important et les inconvénients de la migration eux toujours présent (jeunesse de la solution par rapport à une solution éprouvée et utilisé en production dans des cas très très différents).
Si c'est juste pour du partage de fichier (et qu'il n'y a pas besoin de SMB > 2. Il vaut mieux rester avec Samba 3.
Non, avec la mise à dispo de Samba 4.0, la branche 3.6.x passe en mode maintenance et presque aucune amélioration ne sera faite sur cette branche (juste les corrections de bugs).
Comme indiqué avant, si c'est juste pour un serveur de fichier il suffit de démarrer smbd et potentiellement winbindd.
J'avoue que cette phrase est bizarre pour moi aussi. Alors certe 3 != 4.
Mais Samba 4.0 est bien le successeur des version Samba 3, le changement le plus important est l'introduction de la fonctionnalité de contrôleur de domaine AD, qui est implemantée dans le programme samba, et samba une fois démarré propose les services de partage de fichiers CIFS/SMB/SMB2 et les services d'impression réseau.
Maintenant si le besoin c'est juste un serveur de fichier et/ou d'impréssion membre d'un domaine AD ou bien juste en solitaire alors le programme smbd (et sûrement winbindd et nmbd) doivent être démarrés.
En tant que contrôleur de domaine, samba s'appuie sur le serveur de fichier smbd pour la prise en charge du partage de fichier.
Par exemple si j'ai une machine sous linux qui est connectée dans un réseau AD et que je veux partager des fichiers/répertoires de >cette machine à destination des machines sous Windows, est-ce que je dois utiliser Samba 4 ou Samba 3 ?
Samba 4, mais en démarrant le programme smbd
Je pense que pour la version 4.1 samba sera le seul programme à démarrer que l'on veuille juste un serveur de fichier ( smbd ) ou un contrôleur de domaine AD ou bien juste la gestion de l'autorisation et de l'identification ( winbindd ).
Le temps où il fallait faire du reverse-engineering est donc révolu.
Oui et non, il arrive que les spécifications ne soient pas correctes mais ça reste plus l'exception que la norme de plus la documentation couvre le protocole et un peu le comportement spécifique de chaque version de Windows mais jamais de comment ça se passe à l'intérieur de Windows.
Parfois sur les choses qui sont de la libre interprétation de l'implémentation (la documentation utilise beaucoup de "SHOULD" pour indiquer ce que l'implémentation devrait faire) on obtient des comportements non documentés et la reverse-engineering est parfois nécessaire pour arriver à comprendre ce qui se passe et ainsi pouvoir discuter plus facilement avec les équipes de Microsoft en charge la documentation.
On peut s'en féliciter mais il faut être prudent : Est-ce que toutes les spécifications ont été publiées ?
Toutes les spécifications de tous les protocoles utilisés par Windows ne sont pas à mon avis publiées mais une grosse majorité le sont.
Cf. http://is.gd/HRP3eu
Est-ce que Microsoft ne va pas faire quelques petites modifications sans les publier afin que seules ses solutions fonctionnent bien, juste un peu mieux que les autres ? C'est en cachant quelques API dites à usage interne que Borland a été éliminé car il était ainsi un peu moins performant que Microsoft.
Ca ressemble étrangement à ce que autre entreprise avec un logo en forme de fruit fait sur la plate-forme où il est en monopole…
Je pense que Microsoft ne devrait plus jouer de trop à ce jeu, car pour l'ensemble des protocoles couverts par le jugement ils sont encore tenu à leurs obligations et donc si ils faisaient ceci sciemment cela pourrait aboutir à des poursuites. Mais plus important cela ruinerait l'effort qu'ils ont entrepris pour apparaître (et être) plus "interoperable friendly".
C'est parce que les gens de Microsoft sont des gentils et qu'ils aiment favoriser l'interopérabilité ?
Je pense pas que toutes les personnes de Microsoft soient gentilles mais certaines ont compris que c'est un argument de vente que d'avoir des alternatives inter-operables avec leurs produits.
Heuu…non en vrai c'est parce que Microsoft a perdu en 2004 un procès sur l'interopérabilité intenté par l'Union européenne. Ils ont fait appel et ont été condamnés définitivement en 2007. La commission européenne (merci à elle) a donc réussi à forcer Microsoft à divulguer les informations techniques. L'équipe Samba a ainsi pu en profiter pour améliorer la compatibilité de son logiciel.
Il faut savoir que les obligations de ce jugement obligeait pas Microsoft à documenter ces protocoles (mais seulement ceux couverts) par le jugement et surtout pas à les rendre librement consultable (c'est la raison pour laquelle la PFIF a été créée).
Je pense que le résultat de ce jugement à surtout changé le rapport de force entre différents courants et que les partisans d'un peu plus de collaboration avec la communauté open-source ont acquis plus d'influence.
Moralité : Microsoft c'est toujours pas des gentils.
Moralité, le monde à changé depuis l'an 2000, il faut arrêter de penser qu'une entreprise est binaire (soit pro, soit anti logiciels libres) je pense qu'au contraire différentes nuances expriment. Dans le cas de Microsoft je pense que la réalité c'est qu'il en y a qui sont farouchement contre l'open-source et d'autres qui pensent que c'est une bonne chose pour Microsoft d'être ouvert.
Au risque d'enfoncer une porte ouverte, le but d'une entreprise c'est de faire de l'argent et je pense que toutes les entreprises qui font de l'open-source ("les gentils") le font parce que c'est bon pour les affaires en tout premier lieu.
Me vient quelques questions : certes, le projet est annoncé comme officiellement stable, >mais dans les faits, l'est-il plus ou moins que Samba4 dans ses dernières alpha ?
Compte tenu qu'il est basé sur samba4 je ne vois pas comment il peut être plus stable.
C'est plus une offre cohérente de package (avec surement un suivi de fix de sécurité) et une série de GUI autour d'une base linux + samba 4 + bind + ntp + dhcp.
Me vient quelques questions : certes, le projet est annoncé comme officiellement stable, >mais dans les faits, l'est-il plus ou moins que Samba4 dans ses dernières alpha ?
Je précise un peu ma pensée, durant les quelques tests que j'ai fait de Samba4, celui-ci >me semblait suffisamment au point pour gérer un petit parc de 25 bécannes.
L'équipe plus en charge de Samba4 dans la "samba-team" a toujours indiqué que la notion d'alpha était plus relative aux manques de fonctionnalités (plus particulièrement celles qui existent dans les séries 3.x) qu'un problème de stabilité.
Je pense qu'un réseau avec 10 000 / 20 000 objets (utilisateurs, ordinateurs, contacts …) peut fonctionner raisonnablement bien sur un serveur normal (core 2 recent,2 Go de ram). C'est tout du moins l'environnement que je gérais à une certaine époque.
[^] # Re: Francisation
Posté par ekacnet (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.1. Évalué à 1.
J'abonde dans ton sense (je "plussois"), il y a trop de traduction au mot à mot.
Certaines francisations sont horribles, la carte des périphériques est une mauvaise traduction de device mapper, le terme anglais serait device map.
Je ne pense pas que cartographieur soit une traduction plus appropriée, peut être que le gestionnaire des associations entre périphériques est plus juste.
Le fait est que l'anglais est malheureusement bien mieux adapté pour transmettre un concept en un nombre limité de mots.
# AD DC ?
Posté par ekacnet (site web personnel) . En réponse à la dépêche Atelier serveur Samba : samedi 23 novembre, Paris 13e. Évalué à 1.
Allez vous aborder la (nouvelle) partie contrôleur de domaine pour Active Directory ?
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 2.
Samba (comme toute autre implémentation de l'AD) propose un serveur LDAP qui peut être interroger comme n'importe quel autre serveur LDAP, le protocole LDAP est un des moyen d'interroger la base interne de Samba (les autres moyens sont les "bindings" pyhon, ou bien les outils ldbsearch/ldbadd/ldbmodify)
Il y a un outil pour convertir les schéma au format OL vers un format LDIF: oLschema2ldif, si besoin est ne pas hésiter à poser des questions sur samba-fr@groupes.renater.fr ou samba-technical@samba.org.
[^] # Re: bascule 2000 vers 4.1
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 1.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 3.
Bon c'est pas forcement une excuse mais j'habite depuis quelques temps à l'étranger donc non dépôt m'est pas revenu à l'esprit, mais merci pour la traduction. Le "sondage" me semble plus litigieux.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 6.
Pas mal de réponses à tes questions se trouvent ici:
http://linuxfr.org/news/samba-se-met-enfin-en-4-0-et-prend-en-charge-les-ad
Quand tu dis que openLDAP est le standard, j'ai un peu du mal. Pour moi le standard c'est LDAP ensuite si tu utilise le logiciel A, B ou C qui implémente ce standard ça doit être transparent pour toi.
Pour info FreeIPA utilise 389LDAP comme serveur LDAP et non openLDAP, il y a d'ailleurs une doc qui explique comment migrer vers FreeIPA (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html).
"Tant qu'a utiliser Samba 3 en DC avec le backend OpenLDAP autant en faire de même pour Apache, Bind, Dhcp, la connexion VPN, ftp, la messagerie… "
Qu'est ce qui t'empêche de le faire avec Samba 4?
Dans mon précédant travail j'utilisais Samba 4 et j'avais Apache, OpenVPN, Cyrus IMAP et Postfix qui utilisaient le LDAP de Samba 4 et sans problèmes.
Pour ceux qui utilisent Samba 3 + LDAP il y a un outil de migration: samba-tool domain classicupgrade, j'avoue que je ne sais pas si on migre juste les utilisateurs et les mots de passes ou si on fait plus et si oui jusqu'à quel point.
Il y a surement plus de chose que l'on pourrait faire, mais souvent tout commence quand un utilisateur tente d'utiliser quelque chose et que ça marche pas comme il veut et qu'il en parle sur la liste samba-technical et qu'il essaye de trouver une réponse lui même.
En gros on est que des êtres humains, si on voit quelqu'un de motivé on va avoir plus tendance à l'aider que quelqu'un qui dit juste oh c'est nul ça marche pas et puis on autre LDAP il déchire.
"il va falloir remettre en question des années de centralisation et de travail pour faire communiquer les différentes applications parce que les dev ont décidé d'intégrer leur propre annuaire dans Samba 4. Microsoft est souvent critiqué pour son manque d'ouverture mais je pense que sur le coups Samba 4 est bien placé."
Ah les salauds de développeurs Samba, on pas attendu assez la version 4 ils auraient du attendre d'avoir un support complet openLDAP avant de faire une version stable. Forcement si il n'y a pas d'intégration avec OL c'est la faute du projet Samba, pas la faute du projet openLDAP.
La vérité c'est que quand on a commencé à travailler sur la partie AD il nous fallait un truc pour faire du prototypage rapide et l'utilisation d'un projet externe est pas bien adapté à ce besoin. Au fur et à mesure que l'on a avancé, on s'est rendu compte que notre solution était pas si mal et il n'y avait pas trop de proposition de la part de openLDAP pour nous aider à faire d'OL un citoyen de première classe. Alors à ressources limités on a choisit notre implémentation.
Quand il s'est agit de travailler sur le serveur DNS, on s'est tourné vers BIND mais c'est pas simple de bosser avec ce projet (un indice: tente de soumettre un patch et fait moi signe dans 3 ou 4 ans quand ils vont daigner avoir un coup d'oeil à ton patch …), alors on a regarder d'autres projets et quand on a contacté ceux qui étaient en vie et non toxique ils nous on dit: "le support pour DDNS à la sauce TSIG-GSS, et puis une gestion des ACL plus fine ça nous intéresse pas", alors ben oui on a fait notre propre petit serveur DNS.
"J'ai déjà pensé à ça mais je ne suis pas dev et je ne connais pas toute les subtilités du protocole SMB."
Quand j'ai commencé à bosser sur Samba je connaissais presque rien à LDAP, rien à Kerberos et je connais toujours bien peu de SMB.
Mais je me suis mis sur les choses qui me posait des problèmes à ce moment là et puis j'ai posé des questions et j'ai pris des traces réseau pour mieux comprendre.
J'ai fait pas mal de patches pour Wireshark pour mieux comprendre ce qui se passait au niveau réseau et quels étaient mes problèmes.
Combien même tu n'es pas expert, il y a toujours quelque chose à faire: de la documentation, de l'aide sur le forum et les listes, aider à mieux caractériser les bugs, faire des essais de migration de configuration, …
Il y a sûrement peu que tu puisses faire pour accélérer l'utilisation de OL comme base de stockage pour Samba, mais à l'opposé il y a sûrement beaucoup de chose que tu peux faire pour que la migration vers le serveur LDAP de Samba soit moins misérable ou alors que l'ajout de services à ce LDAP soit plus simple.
[^] # Re: bascule 2000 vers 4.1
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 2.
Le retour que l'on a c'est que ça se passe bien sauf quand on essaye de faire un migration directement depuis Windows 2000.
Car cette version est truffées de drôles de comportements qui ont été corrigés par Microsoft dans Windows 2003.
Aussi on recommande à ceux qui veulent migrer et qui sont encore avec 2000 de passer par une version intermédiaire de Windows (ie. 2003, 2008, ou bien même 2012) de changer le niveau du domaine pour 2003 et aussi pour la niveau de la forêt.
Ensuite joindre un contrôleur Samba.
On recommande aussi de faire un test à blanc avec au moins une copie d'un des contrôleurs dans un réseau complètement isolé du réseau réel (afin que les contrôleurs de test ne se mettent pas à répliquer avec ceux en production …) et faire tourner la chose pendant quelques jours avec quelques clients Windows pour être sûr.
Au cas où il y aurait des problèmes => samba-technical@samba.org ou #samba-technical sur irc.freenode.org
Pour voir le niveau d'intégration de la réplication entre contrôleurs Windows et Samba je conseille de regarder cette vidéo (en anglais):
http://samba.org/tridge/Samba4Demo/s4demo4.ogv
Et plus généralement toutes celles sur cette page: https://wiki.samba.org/index.php/Samba4/videos
[^] # Re: bascule 2000 vers 4.1
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 1.
Ah bon ?
Je pense que c'est moi qui a rédigé la nouvelle pour 4.0 et je pense pas avoir dit ça.
4.0 n'avait pas de support officiel pour plusieurs contrôleurs entre autre parce qu'on pensait que le retour d'expérience n'était pas suffisant et puis aussi parce que le support multi-domaine n'existait pas (il existe toujours pas) et que la réplication de sysvol (toujours pas aussi).
On veut pour l'instant éviter des déconvenues aux admins qui pense que c'est un remplacement à 100%
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 1.
Quelles raisons t'empêchent d'utiliser le serveur LDAP de Samba ?
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 8.
Symas (l'entreprise qui est derrière la majeure partie du développement de openLDAP) a maintenant deux développeurs qui travaillent à faire en sorte que Samba puisse de nouveau utiliser openLDAP comme stockage pour sa base de donnée SAMDB.
La tâche n'est pas simple pour plusieurs raisons:
Quand Samba utilise OL comme stockage ("storage backend"), la bibliothèque LDB va émettre des commandes LDAP pour lire et écrire dans OL, mais pour l'instant OL ne supporte pas les transactions sur les requêtes LDAP, toutes les requêtes en écriture sont définitives (pas de retour arrière ou "rollback"); c'est un gros problème car les transactions sont fréquemment utilisées en interne par Samba en particulier pour le protocole DRS (celui qui gère la réplication de la base sur tous les contrôleurs de domaines).
Il va falloir introduire la notion de transaction sur lDAP (en fait je crois que c'est déjà en cours chez OL) et l'utiliser.
Le développement de Samba utilise des notions d'intégration continue qui fait que chacun des commits dans le repository passe au travers ~1000 tests unitaires et de bout en bout où plusieurs variantes de Samba sont démarrées et testées (serveur de fichier, AD niveau 2003, AD niveau 2008, 2 contrôleurs, …) il va donc falloir intégrer OL dans la mécanique pour qu'une série de tests soient fait avec OL comme base de stockage.
De nombreux tests de bout en bout échouent pour l'instant quand on utilise OL comme stockage, il va falloir résoudre ces problèmes.
Une fois ceci fait, OL pourra être utilisé comme base de stockage, mais attention il faudra encore à ce moment oublier l'idée d'envoyer des requêtes directement à OL, OL sera privatisé pour Samba et seul le serveur LDAP de Samba sera accessible.
Je sais que openLDAP va travailler aussi sur un "overlay" afin que OL soit de nouveau joignable sur les port habituels mais je pense que c'est pas mal de boulot donc il va falloir attendre.
Pour finir il faudra aussi oublier l'idée que l'on puisse mettre à jour une installation OL existante pour lui rajouter la personnalité AD, pour l'instant la commande "provision" de Samba part d'une base vierge. Partir d'une base existante va représenter à lui même un défi compliqué à résoudre et qui dans les cas compliqués ne pourra pas l'être car AD insiste pour avoir sa propre organisation de l'annuaire et son propre schéma qui ont des chances d'être incompatibles avec ceux de la base existante.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba 4.1. Évalué à 3.
Que signifie synchroniser la base interne ?
Quand on demande a 10 personnes différentes on a dix réponses différentes …
Il existe déjà des solutions en utilisant le contrôle dirsync (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/ms677626%28v=vs.85%29.aspx), qui permette de faire du polling (avis aux maîtres Capelo pour la traduction) et de recevoir que le delta des informations modifiées.
Ca permet de synchroniser les deux annuaires, mais il y a toujours une latence.
Dans le repository (avis aux maîtres Capelo pour la traduction) il ya un petit programme en python qui en fait la démonstration cf.
source4/scripting/devel/demodirsync.py.
Pour d'autre synchroniser signifie, avoir une base commune openLDAP/Samba AD et sous entendu utiliser openLDAP comme serveur LDAP pour Samba.
C'est pas possible et c'est pas demain la veille que ça va changer.
[^] # Re: Samba 4, DNS et LDAP
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 4.
Pour l'instant il y a deux serveurs DNS possible pour Samba 4 et je ne pense pas que DNSmasq soit à l'ordre du jour, avec ISC DHCP est capable de mettre à jour les enregistrements DNS pour les machines à qui il attribue une adresse. Malheureusement ISC utilise un mécanisme de clé partagée pour faire ça et pour l'instant ça ne marche qu'avec Bind (et encore pas sûr que ça marche avec tous les backends), j'avais fait un article sur mon blog il y a quelques temps de cela: http://is.gd/Ox78Iv.
Je pense qu'on y pense mais pour l'instant rien n'est fait.
La réponse est oui, et c'est même en cours puisque RedHat fournit par défaut MIT comme implementation Kerberos donc pour pouvoir offrir un paquet Samba 4.0 AD pour RHEL il faut qu'il utilise MIT Kerberos comme KDC.
Mais la question c'est quel est exactement le besoin ?
Pas vraiment, c'est juste les gens d'heimdal étaient plus ouvert aux changements nécessaire du fait des besoins pour avoir un KDC compatible AD.
Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?, la raison c'est qu'il faudrait ré-écrire plein de modules pour Openldap et il se pose la question de maintient de l'intégrité avec les autres serveurs (Netlogon, LSA, …).
L'autre option c'est d'utiliser Openldap comme backend de stockage, on a essayé mais on ne supporte plus parce que cette solution ne marche pas bien:
- Afin que ça fonctionne il faut que l'instance Openldap soit "privatisé" pour Samba sinon il peut se passer de drôles de choses si quelqu'un fait des modifications directement via LDAP en by-passant les modules spécifiques AD.
- Il faut que Samba parte d'une nouvelle installation, pas moyen de faire une mise à jour d'une installation existante car les schemas AD sont partiellement incompatibles.
[^] # Re: Samba 4, DNS et LDAP
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 3.
Pour les besoins d'un AD, il faut que le serveur supporte les mises à jours dynamiques signées (principalement TSIG) et un système d'ACL assez puissant et puis qu'ils permette de faire du multi-master.
Ce qui limite pas mal le choix, ensuite idéalement il devrait pouvoir utiliser les partitions de l'AD ce qui permet de partager avec d'autres implementations (facilite la migration d'un système à l'autre …).
Pour finir je sais que la personne qui s'est occupé du serveur de DNS a pris contact avec les développeurs de dnsmasq mais ceux-ci n'étaient pas trop intéressés, alors certes c'est open-source donc tu peux forker le code et tout le toutim mais en réalité c'est forcement une super idée.
En plus il est possible que l'architecture de ce projet ne soit pas tip top (selon tes critères).
Au final le serveur interne de Samba a été développé en peu de temps (max 2 mois avec principalement un seul développeur) avec très peu de code à proprement parlé car il y a eu réutilisation de beaucoup de "framework" qui avait été développé pour les autres serveurs de samba.
One last thing, comme disait l'autre, Samba reste un projet opensource où certains contributeurs le font principalement sur leur temps libre parce que c'est "fun", c'est le cas du serveur DNS qui a été fait principalement sur le temps libre de Kai Blin parce que ça lui plaisait de faire ça. Il est pas sûr qu'il aurait utilisé ce temps à faire autre chose de plus "utile" si il n'avait pas passé du temps sur ça.
[^] # Re: Samba 4 n'est pas Samba 3
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 3.
Alors je pense que la version 4.0 est aussi conseillée que la dernière version de la branche 3.6 surtout en ce qui concerne la partie serveur de fichier car:
- Il y a eu peu de modification de code dans cette partie
- Chaque commit doit passer une batterie de 1500 tests de bout en bout avant pouvoir être réellement intégré au "master tree git"
- Il a été testé en condition réelle pendant les betas et les release candidate
Après si tu dois faire un choix entre la version 3.6.x où les mises à jours de sécurité sont assurées par la distro ou bien avoir à suivre les différentes alertes de sécurités Samba et faire les mises à jours soit même, je te laisse prendre la conclusion qui va bien en terme de facilité de la chose.
Mais à niveau de support équivalent, il n'y a aucune bonne raison pour rester à la version 3.6.x
[^] # Re: Changement d'époque !
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 1.
Non mais le lien était vraiment trop long …
[^] # Re: Microsoft ?
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 4.
# Lien un peu vieux?
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 3.
Le lien relatif à cette remarque date de 2005 …, au sein d'un AD il y a deux type de réplications qui ont lieu:
La première réplication est implementée depuis 2009 et fonctionne relativement bien, la seconde est toujours en cours de développement et est indispensable pour un bon fonctionnement de Samba dans un environnement mixte (Samba + Windows AD)
[^] # Re: Samba 4, DNS et LDAP
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 7.
Quand on ne sait pas le mieux est de se taire de peur de dire des bêtises !
Les raisons qui ont poussé à la création d'un serveur DNS internes sont :
- Complexité de configuration de Bind 9.x, avec une liste de versions compatibles bien précises, incompatibilité des configuration entre bind 9.7, 9.8 et 9.9
- Automatisation des tests de bout en bout sans dépendance avec bind (car tous les développeurs n'ont pas forcement la bonne version de bind installée.
- Réduction de la mémoire utilisée pour les systèmes types embarqués (beagle board, …)
Les raisons qui ont poussé à la création du serveur LDAP sont:
Les raisons du "retard" sont la complexité des protocoles, si il est facile de faire fonctionner une authentification type AD (la démo a été faite en 2005) il en est moins aisé de faire un serveur qui est suffisamment stable pour que les utilisateurs soient d'accord pour faire fonctionner le cœur du système d'autorisation et d'authentification sur une solution alternative.
Une raison du "retard" est aussi "où sont vos patches", il y a toujours beaucoup de personnes pour critiquer le retard mais assez peu pour proposer des patches pour corriger les bugs ou bien implementer de nouvelles fonctionnalités.
[^] # Re: Samba 4 n'est pas Samba 3
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 1.
Si une nouvelle architecture (NTVFS) étaient bien prévu pour la version 4.0 elle n'a pas été retenue comme implemantation par défaut car entre temps beaucoup de changements introduit par samba4 ont été back-portés au cours des différentes versions 3.x.
Ce fut le cas de la librairie talloc (http://talloc.samba.org) (pour la gestion hiérarchique de la mémoire), de la génération de code pour les protocoles (CIFS, NETLOGON, LSA, …) du stockage des ACLs NT 100% fidèles à ce qui est spécifié du coté client.
De ce fait les avantages relatifs aux changements d'implementation (S3FS -> NTVFS) étaient moins important et les inconvénients de la migration eux toujours présent (jeunesse de la solution par rapport à une solution éprouvée et utilisé en production dans des cas très très différents).
Non, avec la mise à dispo de Samba 4.0, la branche 3.6.x passe en mode maintenance et presque aucune amélioration ne sera faite sur cette branche (juste les corrections de bugs).
Comme indiqué avant, si c'est juste pour un serveur de fichier il suffit de démarrer smbd et potentiellement winbindd.
[^] # Re: Samba 4 n'est pas Samba 3
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 3. Dernière modification le 17 décembre 2012 à 13:35.
J'avoue que cette phrase est bizarre pour moi aussi. Alors certe 3 != 4.
Mais Samba 4.0 est bien le successeur des version Samba 3, le changement le plus important est l'introduction de la fonctionnalité de contrôleur de domaine AD, qui est implemantée dans le programme samba, et samba une fois démarré propose les services de partage de fichiers CIFS/SMB/SMB2 et les services d'impression réseau.
Maintenant si le besoin c'est juste un serveur de fichier et/ou d'impréssion membre d'un domaine AD ou bien juste en solitaire alors le programme smbd (et sûrement winbindd et nmbd) doivent être démarrés.
En tant que contrôleur de domaine, samba s'appuie sur le serveur de fichier smbd pour la prise en charge du partage de fichier.
Samba 4, mais en démarrant le programme smbd
Je pense que pour la version 4.1 samba sera le seul programme à démarrer que l'on veuille juste un serveur de fichier ( smbd ) ou un contrôleur de domaine AD ou bien juste la gestion de l'autorisation et de l'identification ( winbindd ).
[^] # Re: Changement d'époque !
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 6. Dernière modification le 17 décembre 2012 à 07:24.
Oui et non, il arrive que les spécifications ne soient pas correctes mais ça reste plus l'exception que la norme de plus la documentation couvre le protocole et un peu le comportement spécifique de chaque version de Windows mais jamais de comment ça se passe à l'intérieur de Windows.
Parfois sur les choses qui sont de la libre interprétation de l'implémentation (la documentation utilise beaucoup de "SHOULD" pour indiquer ce que l'implémentation devrait faire) on obtient des comportements non documentés et la reverse-engineering est parfois nécessaire pour arriver à comprendre ce qui se passe et ainsi pouvoir discuter plus facilement avec les équipes de Microsoft en charge la documentation.
Toutes les spécifications de tous les protocoles utilisés par Windows ne sont pas à mon avis publiées mais une grosse majorité le sont.
Cf. http://is.gd/HRP3eu
Ca ressemble étrangement à ce que autre entreprise avec un logo en forme de fruit fait sur la plate-forme où il est en monopole…
Je pense que Microsoft ne devrait plus jouer de trop à ce jeu, car pour l'ensemble des protocoles couverts par le jugement ils sont encore tenu à leurs obligations et donc si ils faisaient ceci sciemment cela pourrait aboutir à des poursuites. Mais plus important cela ruinerait l'effort qu'ils ont entrepris pour apparaître (et être) plus "interoperable friendly".
[^] # Re: Microsoft ?
Posté par ekacnet (site web personnel) . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 10. Dernière modification le 17 décembre 2012 à 07:20.
Spoiler: je suis membre de la 'Samba-Team'
Je pense pas que toutes les personnes de Microsoft soient gentilles mais certaines ont compris que c'est un argument de vente que d'avoir des alternatives inter-operables avec leurs produits.
Il faut savoir que les obligations de ce jugement obligeait pas Microsoft à documenter ces protocoles (mais seulement ceux couverts) par le jugement et surtout pas à les rendre librement consultable (c'est la raison pour laquelle la PFIF a été créée).
Je pense que le résultat de ce jugement à surtout changé le rapport de force entre différents courants et que les partisans d'un peu plus de collaboration avec la communauté open-source ont acquis plus d'influence.
Moralité, le monde à changé depuis l'an 2000, il faut arrêter de penser qu'une entreprise est binaire (soit pro, soit anti logiciels libres) je pense qu'au contraire différentes nuances expriment. Dans le cas de Microsoft je pense que la réalité c'est qu'il en y a qui sont farouchement contre l'open-source et d'autres qui pensent que c'est une bonne chose pour Microsoft d'être ouvert.
Au risque d'enfoncer une porte ouverte, le but d'une entreprise c'est de faire de l'argent et je pense que toutes les entreprises qui font de l'open-source ("les gentils") le font parce que c'est bon pour les affaires en tout premier lieu.
[^] # Re: Enfin une bonne nouvelle
Posté par ekacnet (site web personnel) . En réponse à la dépêche Resara Server 1.1.2. Évalué à 1.
Je connais au moins une entreprise qui a migré son KDC de pure heimdal vers Samba 4 et ceci pour gérer simplement des clients osX.
[^] # Re: Sympa
Posté par ekacnet (site web personnel) . En réponse à la dépêche Resara Server 1.1.2. Évalué à 3.
C'est plus une offre cohérente de package (avec surement un suivi de fix de sécurité) et une série de GUI autour d'une base linux + samba 4 + bind + ntp + dhcp.
Il y a quelques alternatives qui existent qui proposent une distribution packagée:
* univention (http://www.univention.de/en/download/preinstalled-vmware-images/)
* sernet (http://ftp.sernet.de/pub/samba4-appliance/)
L'équipe plus en charge de Samba4 dans la "samba-team" a toujours indiqué que la notion d'alpha était plus relative aux manques de fonctionnalités (plus particulièrement celles qui existent dans les séries 3.x) qu'un problème de stabilité.
Je pense qu'un réseau avec 10 000 / 20 000 objets (utilisateurs, ordinateurs, contacts …) peut fonctionner raisonnablement bien sur un serveur normal (core 2 recent,2 Go de ram). C'est tout du moins l'environnement que je gérais à une certaine époque.
[^] # Re: Trop de bière
Posté par ekacnet (site web personnel) . En réponse à la dépêche Resara Server 1.1.2. Évalué à 2.
Il y a plus d'une personne qui utilise la dernière version (alpha20) en production avec plusieurs centaines d'utilisateurs et 3 ou 4 DCs.