Modifications entre les versions 4 et 5
Version 4 à la date du 2009-05-08 18:41:40
Taille: 2589
Éditeur: MoussaNombre
Commentaire: Mise à jour / correction
Version 5 à la date du 2009-05-25 16:48:19
Taille: 3763
Éditeur: AlexandreDomont
Commentaire: quelques éléments de réponse en attendant mercredi
Texte supprimé. Texte ajouté.
Ligne 24: Ligne 24:
 * Gestion des partages selon l'appartenance aux groupes. Demander à Alex son script des connexions aux partages pour s'en inspirer.   * <---@AlexandreDomont---
  * Pour le DHCP, pas besoin de AD.
  * Pour le DNS, par contre, il faut le garder en DNS primaire sur les client Windows pour assurer l'authentification
  * Tant qu'il y aura des clients Windows en nombre suffisant pour justifier d'une authentification centralisée...je pense qu'il faudra le garder.
  * ---@AlexandreDomont--->
 * Gestion des partages selon l'appartenance aux groupes. Demander à Alex son script des connexions aux partages pour s'en inspirer.
  * ---@AlexandreDomont : de quoi parlez-vous exactement ?
Ligne 26: Ligne 32:
 * Profil (/home) distante - tolérance aux pannes. Un seul serveur d'authentification comporte un risque. Aucun session "centralisé" ne pourra pas être ouvert s'il tombe en panne ou si les clients ne pouvent pas le contacter pour autre raison quelconque (réseau, switch, etc). Y avait t-il des reflexions sur ce question ?     'De plus je (Darko) remarque que même la session local est ralenti si pas de connexion au réseau. Est-ce normal, déjà vu ???   * ---@AlexandreDomont : assurément et sans hésitation CUPS
* Profil (/home) distante - tolérance aux pannes. Un seul serveur d'authentification comporte un risque. Aucun session "centralisé" ne pourra pas être ouvert s'il tombe en panne ou si les clients ne peuvent pas le contacter pour autre raison quelconque (réseau, switch, etc). Y avait t-il des réflexions sur ce question ? 'De plus je (Darko) remarque que même la session local est ralenti si pas de connexion au réseau. Est-ce normal, déjà vu ???
  * ---@AlexandreDomont : Pour ma part, je pense soit à
   * 2 serveurs synchrones NFS/SAMBA/NSSMSQL
   * 1 serveurs NFS/SAMBA (sauvegardes rapprochées 6h) + 1 OpenVZ NSSMSQL (souplesse de restauration)
   * Dans le délire, on pourrait même imaginer 1 OpenVZ NFS/SAMBA attaché à un éléments de stockage (iSCSI, eATA...)
  * ---@AlexandreDomont
Ligne 30: Ligne 41:
  * ---@AlexandreDomont : mon point de vu ;) : je ne préfère pas toucher à la conf locale, les comptes locaux sont sur le /home et les comptes centralisés sur le /net/serveur/home, comme ça, c'est plus clair pour moi, on sépare bien les choses. Maintenant, je pense que les avis sont partagées, il faut discuter.

Réunion technique sur la migration Ubuntu

Personnes présentes :

Objectif

L'objet de cette première réunion était d'identifier les services nécessaires pour mettre en place une infrastructure bureautique basé sur des serveurs Debian et des postes client Ubuntu. Par la suite on fera une visio avec AlexandreDomont pour profiter de son expérience vu que nos architectures de réseau bureautique sont semblables.

Points saillants

Situation actuelle

  • la gestion des comptes utilisateurs, l'authentification, le dns, le dhcp sont actuellement gérés par des serveurs M$ Windows 2003
  • les imprimantes sont accessibles directement via le réseau ou via le serveur d'impression Windows
  • le serveur Debian pour NFS et l'authentification centralisé (authnss) est en phase de test. Graduellement on va migrer les postes Ubuntu de service ARI.

Questions à élucider pour la phase transitoire

A terme les serveurs bureautiques seront des serveurs Debian. Pour avancer dans la migration et surtout bien gérer la phase de transition (mode mixte) nous avons identifier les sujets de discussion suivantes:

  • DNS et DHCP : Les enjeux: AD (active directory) a besoin d'avoir son DNS et son DHCP pour fonctionner. Alors gardera-t-on le DNS/DHCP coté Windows en attendant d'avoir migrer tous les postes sous Ubuntu ? Peut-on contourner cette contrainte de AD ?
    • <---@AlexandreDomont---

    • Pour le DHCP, pas besoin de AD.
    • Pour le DNS, par contre, il faut le garder en DNS primaire sur les client Windows pour assurer l'authentification
    • Tant qu'il y aura des clients Windows en nombre suffisant pour justifier d'une authentification centralisée...je pense qu'il faudra le garder.
    • ---@AlexandreDomont--->

  • Gestion des partages selon l'appartenance aux groupes. Demander à Alex son script des connexions aux partages pour s'en inspirer.
  • Gestion des imprimantes, via un serveur d'impression ou en direct ?
  • Profil (/home) distante - tolérance aux pannes. Un seul serveur d'authentification comporte un risque. Aucun session "centralisé" ne pourra pas être ouvert s'il tombe en panne ou si les clients ne peuvent pas le contacter pour autre raison quelconque (réseau, switch, etc). Y avait t-il des réflexions sur ce question ? 'De plus je (Darko) remarque que même la session local est ralenti si pas de connexion au réseau. Est-ce normal, déjà vu ???
    • ---@AlexandreDomont : Pour ma part, je pense soit à

      • 2 serveurs synchrones NFS/SAMBA/NSSMSQL
      • 1 serveurs NFS/SAMBA (sauvegardes rapprochées 6h) + 1 OpenVZ NSSMSQL (souplesse de restauration)
      • Dans le délire, on pourrait même imaginer 1 OpenVZ NFS/SAMBA attaché à un éléments de stockage (iSCSI, eATA...)
    • ---@AlexandreDomont

  • Pour essayer de solutionner le point précédent, nous avons pris en considération d'avoir un serveur secours qui serait synchronisé avec le serveur "Maitre". La fréquence de synchronisation reste à déterminer (une ou deux fois par jour ?).
  • Analyser la configuration des /home locaux. Lancer la discussion : les garder comme /home vs /home-local, avantages, soucis, facilité d'implantation, etc.
    • ---@AlexandreDomont : mon point de vu ;) : je ne préfère pas toucher à la conf locale, les comptes locaux sont sur le /home et les comptes centralisés sur le /net/serveur/home, comme ça, c'est plus clair pour moi, on sépare bien les choses. Maintenant, je pense que les avis sont partagées, il faut discuter.

ZA/Montréal/Projets/MigrationUbuntu/Réunion20090507 (dernière édition le 2009-05-25 16:48:19 par AlexandreDomont)