Samba, le logiciel client/serveur pour communiquer avec le monde qui fait peur (Windows pour les intimes), arrive en version 4.1. Pour rappel, depuis la version 4, il est possible d'en faire un contrôleur de domaine Active Directory.
Le détail des nouveautés dans la seconde partie de la dépêche.
SMB 2 et 3 pour les outils clients
Les outils clients de samba (smbclient, smbacls…) permettent d'utiliser les nouvelles versions du protocole SMB (SMB 2 et SMB 3). Il faut noter que ces versions ne permettent pas d'utiliser les extensions Unix car elles ne sont pas définies pour ces protocoles. Par défaut, c'est toujours SMB 1 qui est utilisé ; on peut forcer la version dans le fichier de configuration pour toutes les connexions ou via la ligne de commande, par exemple :
smbclient //server/share -Uuser%password -mSMB3
Transport chiffré
Samba avait déjà cette fonctionnalité avec les extensions Unix, elle est maintenant disponible pour dialoguer avec un serveur Windows (2012 ou 8, car il faut SMB 3). Il faut spécifier l'option -e pour l'activer.
La réplication de la base de donnée du répertoire (AD DC mode)
Elle a été revue afin d'être plus rapide et juste. Cela a pour effet de bord de permettre la réplication de domaines ayant beaucoup changé, qui avait tendance à échouer avec les versions précédentes.
Copie côté serveur
SMB 2 avait introduit une fonctionnalité pour permettre la copie de fichiers côté serveur, elle est maintenant prise en charge. Les clients qui l'utilisent, tels que Windows 2012, devraient voir de grosses améliorations de performances.
De plus, Samba prend explicitement Btrfs en charge pour rendre cette copie encore plus rapide.
SWAT a été retiré
L'utilitaire de configuration web a été retiré. Cela décevra sans doute beaucoup d'utilisateurs mais les failles de sécurités commençaient à s'accumuler et comme il n'y a aucun mainteneur pour l'application, les développeurs ont préféré la retirer.
Aller plus loin
- Site officiel (855 clics)
- Notes de version (337 clics)
# Précisions sur la "copie côté serveur"
Posté par AP . Évalué à 10.
Il faut comprendre par là que, lorsque vous dupliquez un fichier sur le serveur Samba, son contenu ne transite pas en aller vers le client et en retour sur le serveur. La seule chose qui transite sur le réseau est l'ordre de copie. En outre, l'intégration avec BTRFS implique que la création du nouveau fichier se fera sans consommer d'espace supplémentaire. Le nouveau fichier sera vu comme indépendant du précédent (inode et attributs distincts) mais pointera initialement vers les mêmes blocs disques. C'est un des avantages des systèmes de fichiers modernes (tels que ZFS ou BTRFS) qui intègrent nativement la notion de snapshot.
[^] # Re: Précisions sur la "copie côté serveur"
Posté par Pierre-Marie D . Évalué à 2.
Doit-on supposer que le "déplacement côté serveur" fonctionnera aussi comme ça ?
Ça sera bien pratique une fois intégré comme il faut dans gvfs et cie.
Parce qu'à chaque fois que je veux ranger un peu le NAS, je suis obligé de passer par l'IHM web sinon je me paye l'aller/retour sur ma machine.
[^] # Re: Précisions sur la "copie côté serveur"
Posté par ʭ ☯ . Évalué à 1.
Ça m’étonnerait que ton NAS - qui fonctionne certainement avec un vieux SaMBa - implémente SMB3 …
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Précisions sur la "copie côté serveur"
Posté par Pierre-Marie D . Évalué à 1.
Les gars de chez Syno ne sont pas avars sur les mise à jour moyennant que le hardware le supporte.
Et puis si c'est pas pour ce NAS ci, ça sera pour un autre.
[^] # Re: Précisions sur la "copie côté serveur"
Posté par Argon . Évalué à 1.
Je le fais très bien sur un Synology avec nfs. Ton NAS ne te permet pas de le faire ?
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Précisions sur la "copie côté serveur"
Posté par Pierre-Marie D . Évalué à 1.
Je préfère rester en Samba parce que je ne comprends pas bien la gestion des droits avec NFS.
[^] # Re: Précisions sur la "copie côté serveur"
Posté par FantastIX . Évalué à 2.
Je peux me tromper mais le déplacement n'a pas besoin d'une telle astuce étant donné que si un fichier est déplacé au sein d'un même volume, il ne provoque qu'un changement au niveau de l'inode, pas du contenu, ce qui est beaucoup plus rapide, même lorsque la commande vient d'un client réseau.
# Liaison LDAP SAMBA vers Openldap
Posté par Ago . Évalué à 6.
Je profites de cette nouvelle pour demander aux barbus LDAP / SAMBA si il y a des évolutions prévues sur la synchronisation de la base interne LDAP de SAMBA vers un openldap existant ?
Je comprends tout à fait le choix d'avoir un annuaire interne à SAMBA 4 en terme d'évolution et maintien mais ça limite énormément l'intégration de celui-ci dans une infra existante.
J'ai regardé https://wiki.samba.org/index.php/Samba4/LDAP_Backend mais ça ne me semble pas pertinent pour une infra de production.
Je cherches donc un système de synchronisation entre l'annuaire interne de SAMBA et un openldap. Si quelqu'un à des pistes ou des remarques je suis preneur.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par SalvadorDalek . Évalué à 1.
Si ce que tu cherches, c'est l'intégration avec une infra windows existante, il faut regarder du côté de FreeIpa qui orchestre les composants ldap(389DS)/kerberos(MIT)/dns(BIND) et utilise Samba 4.x pour participer à des trusts avec des domaines windows comme s'il en était un lui-même.
Cela permet par exemple des scénarios où tes machines linux gérées par l'IPA trustent les utilisateurs d'un domaine windows.
Bien à toi.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ʭ ☯ . Évalué à 5.
Si j'ai bien compris ce franglais :
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par SalvadorDalek . Évalué à -8.
Mwais, si tu veux et si tu n'as rien d'autre à dire d'intéressant…
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par SalvadorDalek . Évalué à -3.
Pour complète, je dirais que si le fait de défendre la langue française est tout à fait louable,
le faire de la sorte est très peu courtois pour ne pas dire grossier.
Quelqu'un qui s'intéresse réellement à la langue française plutôt qu'à prendre la pose sur un forum aurait fait autrement que de balancer une commande 'sed' (ce qui n'est pas du Français à ce que je sache) à la figure de l'interlocuteur sans même s'adresser à lui. C'est une attitude dénigrante qui ne fait pas avancer le débat, et cela ne s'inscrit certainement pas dans esprit de collaboration et d'échange.
Dommage également que certains pensent que ce genre d'attitude mérite encouragement.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par Ago . Évalué à 2.
Merci pour la découverte, mais dans mon cas je n'ai pas d'AD Windows et souhaite m'en passer.
Par contre j'ai des clients Windows 7/8 et un contrôleur de domaine répliqué avec mon annuaire m’intéresse fortement.
Le soucis c'est que de ce que j'ai pu lire je suis obligé de rester sur samba 3 si je veux pouvoir coupler mon PDC avec mon openldap. Sauf que la version "AD" de samba 4 amène une souplesse au quotidien dans l'administration du parc windows, d’où mon envie de répliquer l'annuaire interne d'un samba 4 vers un openldap existant.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . Évalué à 1.
Quelles raisons t'empêchent d'utiliser le serveur LDAP de Samba ?
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par KPTN (site web personnel, Mastodon) . Évalué à 5.
Le plus simple pour synchroniser les deux est d'utiliser LSC
Sinon OpenLDAP pourra certainement bientôt devenir le backend LDAP de Samba 4, les travaux sont en cours. Il y aura sans doutes des annonces importantes à la LDAPCon cette année ;)
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par SalvadorDalek . Évalué à 1.
Ouh, intéressant outil, je ne connaissais pas..
à mon avis ça ne règle pas tous les problèmes, mais ça peut offrir une sérieuse base pour en régler tout de même une grosse partie.
Merci
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . É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 Philippe M (site web personnel) . Évalué à 6.
Je comprends (vaguement) les contraintes techniques et différences de fonctionnement entre Samba 4 et OpenLDAP mais je trouve étonnant le choix qui a été fait par l'équipe de Samba 4.
Depuis des années on se bat pour la centralisation des informations utilisateurs, depuis des années OpenLDAP est un "standard" dans l'univers Unix/Linux, depuis des années les applications majeurs de l'éco-système OpenSource supportent la communication avec OpenLDAP, Samba 3 en fait partie. Je parie qu'il y a de nombreuses installations de Samba 3 en prod en mode NT4 (j'en fais partie). 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…
Avec l'arrivé de Samba 4 et l'obligation de migrer à plus ou moins long terme, si l'on veut pouvoir continuer à faire communiquer l'environnement Windows avec l'infra serveur Linux, 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é.
Alors oui ça évoluera dans le temps, dans x années nous retrouverons le backend OpenLdap mais en attendant Windows 7 et 8 sont déjà là, tout comme Windows serveur 2008, 2013… J'entends déjà dire : "t'es pas content sort toi les doigts et aide". J'ai déjà pensé à ça mais je ne suis pas dev et je ne connais pas toute les subtilités du protocole SMB. Mon boulot c'est trouver des solutions viable pour l'entreprise et m'assurer qu'elle garde son autonomie face à des éditeurs logiciels/matériels. Je pourrais me séparer de Windows sur les postes utilisateurs, malheureusement ce n'est pas possible à cause d'une application qui n'existe pas dans l'univers Linux (client ERP) et dont le client web est anti ergonomique pour nos usages (me parler pas de changer d'ERP).
J'espère me tromper mais lorsque je lis les différents commentaires j'ai l'impression que l'impossibilité d'utiliser OpenLDAP en backend avec Samba 4 sera un frein à une migration.
Born to Kill EndUser !
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . É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: Liaison LDAP SAMBA vers Openldap
Posté par ariasuni . Évalué à 5.
Quand bien même. Comme même!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par Philippe M (site web personnel) . Évalué à 1.
Effectivement tout est dit dans ton premier lien. Impossible d'utiliser le backend LDAP et pas de schémas personnalisés… Du coups pas de dhcp, pas d'overlay je suppose. Une solution totalement fermé pour le moment en tout cas.
Oui OpenLDAP n'est pas le standard c'est LDAP qui l'est, pardon.
Oui ils auraient pu le faire, il me semble que l'implémentation OpenLdap est très courante dans les distributions utilisable en production… Après OpenLdap n'est pas forcement innocent mais avoir un contrôleur de domaine apporte énormément en terme de gestion du parc machines/utilisateurs donc c'est une application critique. J'aurais préféré attendre un an de plus et pouvoir migrer mon archi au petits oignons plutôt que me retrouver avec d'un côté l'annuaire Samba 4 et un autre annuaire que je suis obligé de synchronisé parce que dans Samba 4 j'ai pas le droit de toucher au schéma LDAP… Chose qu'il est possible de faire il me semble dans AD ?
Toujours le même couplet… Oui il y a toujours à faire pour aider suivant ces compétences et je n'hésite pas à le faire. Mais ça ne m'enlève pas l'idée que être incompatible (pour le moment) avec un backend ldap est une erreur.
Born to Kill EndUser !
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par claudex . Évalué à 4.
Samba 4 ont intégré un annuaire pour une raison pratique, c'était beaucoup plus simple pendant le développement, durant lequel ils sont dû comprendre comment fonctionnait AD en interne, de ne pas se compliquer la vie avec encore plus de contraintes (sinon, je pense qu'on attendrait toujours la version 4).
Mais je ne comprends pas pourquoi ce serait un frein. J'ai l'impression que les gens ont leur schéma et s'imaginent qu'ils vont pouvoir intégrer ça facilement avec l'AD alors que ce dernier a un schéma très strict et qu'il faudra énormément de modifications pour que ça marche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . É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: Liaison LDAP SAMBA vers Openldap
Posté par ariasuni . Évalué à 5.
Ça signifie sondage. Merci au passage pour l'invitation à traduire, je sais ce qu'est le polling maintenant. :p
T'abuses quand même, dépôt c'est une traduction connue (dépôt git, dépôt de logiciel…).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . É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 ariasuni . Évalué à 3.
Anéfé, mais ça décrit bien le fonctionnement.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par Ago . Évalué à 1.
Je parle bien de synchronisation entre deux annuaires.
Merci pour la découverte de dirsync et merci à clément pour le rappel de l'existence de LSC.
Ça me fait deux pistes concrètes pour avancer.
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.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet (site web personnel) . É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.
# bascule 2000 vers 4.1
Posté par rupteur . Évalué à 2.
J'étudie la possibilité de remplacer un Windows 2000 serveur par samba 4.1
Existe t-il des outils permettant de récupérer les SID du serveur,utilisateurs,ordinateurs pour les réinjecter dans samba 4.1 ?
Merci.
[^] # Re: bascule 2000 vers 4.1
Posté par ʭ ☯ . Évalué à 1. Dernière modification le 18 octobre 2013 à 14:04.
Ayant migré de 2OOO vers 2008, je dirais qu'il te faut ajouter des Samba 4.1 comme contrôleurs de domaine, t'assurer qu'ils fonctionnent comme voulu sur un réseau isolé des 2000, et éteindre les 2000.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: bascule 2000 vers 4.1
Posté par Larry Cow . Évalué à 2.
Dans ce cas-là, tu pratique une migration (i.e. adjonction des S41 comme contrôleurs secondaires, puis promotion des S41 et suppression des anciens contrôleurs)? Ou bien c'est un nouveau domaine que tu crées?
J'avais (vaguement) lu un truc à la sortie de Samba4 comme quoi la réplication n'était pas complètement fonctionnelle, et donc empêchait (ou compliquait salement, je ne me souviens plus) ce genre de migration "à tiède".
[^] # Re: bascule 2000 vers 4.1
Posté par rupteur . Évalué à 1.
il s'agit du même domaine.
Effectivement j'avais aussi pensé à la réplication puis promotion, mais comme je ne l'ai jamais pratiqué…
Si quelqu'un a des retours (réussis ou non avec samba).
[^] # Re: bascule 2000 vers 4.1
Posté par Larry Cow . Évalué à 4.
Avec Samba, je n'ai pas mais - et c'est pour ça que je demande - j'ai de très mauvaises expériences de ça dans le monde Microsoft. J'ai eu à le faire plusieurs fois entre NT/2K3, 2K/2K3, et 2K3/2K3… et ça tient souvent de la magie noire. Tu fais comme c'est marqué dans le manuel, et quelque-fois ça marche, et quelque-fois ça marche pas. L'expérience m'avait montré à l'époque (et c'était repris dans certaines documentation) qu'attendre un temps non-spécifié entre certaines étapes permettait de faciliter les choses, une partie de l'opération se déroulant en tâche de fond et sans indicateur de fin.
Bref, si ça se passe ne serait-ce qu'un tout petit peu mieux avec Samba, c'est déjà un grand pas en avant.
[^] # Re: bascule 2000 vers 4.1
Posté par rupteur . Évalué à 1.
Merci pour ces éclaircissements.
je pense qu'il ne me reste plus qu'à tester et espérer :)
[^] # Re: bascule 2000 vers 4.1
Posté par ekacnet (site web personnel) . É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) . É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: bascule 2000 vers 4.1
Posté par Larry Cow . Évalué à 2.
Je n'ai pas dit que j'avais lu ça sur LinuxFR. Je suis les ReleasesNotes de Samba4 depuis les alphas, et j'avais compris (cru comprendre?) un truc comme ça.
Ça, ce n'est pas forcément pénalisant pour tout le monde (loin s'en faut). Ou alors je n'ai toujours pas compris l'utilité du multi-domaine, mais tous les ADs que j'ai croisé fonctionnaient avec un seul domaine.
Ç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?
[^] # Re: bascule 2000 vers 4.1
Posté par ekacnet (site web personnel) . Évalué à 1.
[^] # Re: bascule 2000 vers 4.1
Posté par Larry Cow . Évalué à 2.
Il y a des pointeurs (voire des scripts tous faits) pour ce genre de choses? Ça permettrait de nuancer largement le côté bloquant de la chose.
# Commentaire de néophyte
Posté par Mathias Bavay (site web personnel) . Évalué à 3.
/disclaimer
Je n'ai jamais fait de gestion d'annuaire, ni de gestion de parc, juste l'administration de quelques serveurs isolés (et à la mode dinosaure Unix pur et dur).
/disclaimer
Il y a quelques semaines, j'ai du configurer une Ubuntu récente pour l'intégrer dans l'infrastructure de notre institut. En gros, gestion des utilisateurs par AD ainsi que gestion des ressources réseau (une poignée de volumes à monter)
Après quelques jours à tenter de faire fonctionner l'engin, installer/désinstaller/réinstaller plein de packages, après des heures sur le net, j'ai du admettre ma défaite et piteusement demander à nos admins de prendre en charge ma machine (et au passage de la rétrograder vers une Ubuntu plus ancienne, seule supportée).
Donc est que c'est uniquement moi, ou bien est ce que AD+Linux (voir même AD tout seul) c'est une monstrueuse usine à gaz, super compliquée et passablement fragile?
Mathias
PS: et vous avez le droit de me dire qu'il faut laisser faire les pros, on est vendredi!
[^] # Re: Commentaire de néophyte
Posté par SalvadorDalek . Évalué à 1.
Salut,
AD et Linux, ça a toujours été une petite foire d'empoigne… surtout avant windows 2008 où il fallait faire des extensions de schéma sur AD juste pour avoir les attributs unix de base.
Personnellement, sur de très grands parcs, je n'ai jamais réussi à obtenir un résultat satisfaisant.
En dehors d'une approche IPA, tu peux toujours implémenter une infrastructure ldap (avec un peuplement manuel ou généré par scripts depuis l'AD) et une relation de confiance entre ton domaine kerberos et ton domaine AD de sorte que tu bénéficie de l'authentication transitive de kerberos (SSO) tout en ayant une base d'autorisation ldap saine et adaptée à ta plateforme unix/linux.
Avec cette approche, tu peux en outre gérer proprement les identifiant de tes services dans kerberos et distribuer les fichiers keytabs sans devoir passer trois heures à discuter avec tes administrateurs windows pour essayer de leur faire comprendre de quoi il s'agit et à essayer de comprendre ce qu'ils demandent.
Bien à toi
[^] # Re: Commentaire de néophyte
Posté par Loïc Blot (site web personnel) . Évalué à 2.
Personnellement j'utilise Puppet pour gérer mon parc de machines de salles de cours sous Linux (une cinquantaine de machines) et déployer des logiciels avec un login pam_ldap configuré via puppet et autofs + pam_mkhomedir et ca tourne pas mal du tout. Peut être serait-ce une bonne solution dans ton cas ?
Veepee & UNIX-Experience
[^] # Re: Commentaire de néophyte
Posté par SalvadorDalek . Évalué à 2.
Salut,
quand je parlais de problème pour déployer les keytabs, je parlais plutôt d'un problème de contenu plutôt que de contenant… Quand tu dois intégre du linux dans un domaine AD dans lequel tu n'as pas les privilèges suffisants pour générer les keytabs, ton problème n°1 n'est pas la diffusion de ceux-ci sur les bonnes machines mais simplement de les obtenir.
Sinon c'est sûr que puppet est un excellent outil pour la configuration de masse.
Bien à toi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.