From OCS Inventory NG

Contents 1 Introduction 2 Champ de fonctionnalité OCS 3 Télédistribution 4 Gestion de la configuration 5 Architecture générale 6 Schema de base de données 7 GUI 8 Agent unified 9 Agent Win32 10 OCS et les partenaires 11 OCSInventory-ng.org

Introduction

Le meeting OCS à eu lieu le vendredi 06 mars 2009 à l'université de Nantes.

Nous adressons nos chaleureux remerciements à l'Université de Nantes pour la mise à disposition de ses locaux.

• Présentation de la Core Team

 Pascal Danek
 Didier Liroulet
 Emmanuel Guillory
 Erwan Goalou
 Goneri Le Bouder
 Guillaume Protet

• Brève introduction sur ce que n'est pas le meeting (pas une formation, pas une information, pas un évenement de support...)
• Tour de table. Présentations des participants
• Présentation des sujets qui seront abordés tout au long de la journée

Champ de fonctionnalité OCS

• Fonctionnalités extra inventaire

 Le nom du projet est-il encore pertinent? 
 l'utilisation de OCS commence par l'inventaire et ensuite viennent les autres fonctionnalités.
 Pour une vision plus juste du projet, généralisation de la phrase en dessous du logo?
 "Le système open source d'inventaire automatisé et de télédéploiement"

• Telediffusion

 Problème de visibilité. Solutions proposées:

=> Changer le site web pour afficher plus la telediff => Mettre a disposition des paquets pour faciliter l'utilisation de la télédiff. (prévu dans le wiki) => Note: mettre plus en avant le wiki dans le site web, notamment pour la documentation

• Prise de contrôle à distance?

 Faut-il mettre cette fonctionnalité dans la roadmap?
   => oui mais avec un outil déjà existant. 
   => proposer l'installation d'un applicatif de cette famille par la télédiffusion OCS
   => Dans l'interface OCS, juste un lien pour appeler le logiciel
   => particulièrement intéressant de la mettre dans OCS puisqu'on dispose des remontées évenementielles des adresses IP en cas de changement

• Déploiement d'image systeme?

 Ne fera pas l'objet d'une fonctionnalité intégrée mais la méthode pour le faire sera disponible dans le wiki  

• Informations administratives plus complexes (possibilité de gestion ultra simple)

  Historiquement OCS se limite à l'implémentation de fonctionnalités techniques. 
  OCS=> outil de gestion de parc(souvent GLPI).
  Mais Peut-on améliorer OCS pour répondre simplement à un besoin simple? Fonctionnalités Light?
  Le but n'est pas de devenir un outil de gestion de parc.
  Les TAG sont déjà une entorse au périmètre technique. Leur simple évolution peut couvrir le besoin. 
  Ex: champ commentaire éditable pour un groupe ou une machine, information adminitrative de type "ascenseur".

Télédistribution

• Serveurs de redistribution

  Le problème de redistribution des paquets au plus près de la machine est actuellement traité par l'utilisation massive des serveurs de 
  redistribution. Conceptuellement, ces serveurs sont en faible nombre et maîtrisés. Les problèmes de contention du réseau, et de manière générale, 
  la prise en compte de la topologie du réseau doivent être prise en compte en paramètrant pour des groupes dynamiques, statiques ou même jusqu'au
  niveau machine, les vitesses de téléchargement. On voit donc que la redistribution "au plus près" est une fonctionnalité de OCS qu'il reste à 
  développer. L'utilisation des "groupes de serveurs de redistribution" est simplement un moyen de contourner son absence. Il ne fait que mettre 
  en évidence l'absence de lien conceptuel entre OCS et ces serveurs
  Cette fonctionnalité pourrait malgré tout être conservée à terme afin de garder un paquet longtemps sur un serveur proche. 

• Redistribution des paquets au plus près de la machine

  Pour la redistribution au plus près en mode "serverless" une évolution des agents est nécessaire. Ils auront la capacité 
  de distribuer les fragments déjà téléchargé aux machines de son LAN. 
  Cela suppose l'ouverture d'un port sur l'agent. Cette fonctionnalité sera désactivable.
  Il est également évoqué l'intéret de signer chaque fragment plutôt que le paquet de sorte à ne pas télécharger entièrement un paquet en erreur.
  

• Désactivation de SSL

  Il est jugé utile de pouvoir le désacitver à des fins de test. 
  Etude prévue pour savoir si la fonctionnalité de désactivation affaibli le modèle global de sécurité.
  Cependant des alertes sur l'interface signaleront le manque de sécurité.

• Alternative à SSL

  Signer les paquets avec GPG pour simplifier l'utilisation de la télédiffusion 
  Ceci est facilement réalisable compte-tenu des mécanismes de vérification des signatures 

• SSL user friendly

  Proposition d'un assistant pour mettre en place le SSL. Mais techniquement, cela est compliqué.

Gestion de la configuration

 Le but est de fournir à travers OCS, un point d'entrée unique pour visualiser et paramètrer la configuration des machines aussi bien "unix like"
 que "windows". Il est déjà possible de faire cela par la télédiffusion mais il faut créer un paquet, le script etc. 
 Deux choix envisagés
    => Augeas

Librairies C NE touche pas ce qu'il ne connait pas.

    => Puppets.
 L'agent OCS pourrait faire appel à ces deux outils. Modification dans l'interface pour rendre simple cette fonctionnalité.

 L'agent Puppets est utilisable en mode Standalone. On pourrait donc utiliser l'agent OCS pour le manipuler.
 Problème: un nouvel agent sur les postes et puppets ne fonctionne que sous linux.
 Si AUGEAS est utilisé, seule une librairie est nécessaire.
 Puppets utilise déjà AUGEAS.
 
 Au niveau de l'interface utilisateur, on voudrait que les manipulations soient graphiques et qu'elles soient le plus homogène possible
 pour un linux ou un windows.

Architecture générale

• Fonctionnement d'OCS.

 Un applicatif externe peut utiliser les données OCS avec un service SOAP.
 Faut-il modifier cette méthode? Faut-il donner la possibilité d'utiliser les agents sans le serveur?
 La réponse à cette question conditionne l'investissement dans le serveur, le servcie SOAP et l'interface.
 Doit-on juste proposer une interface par défaut? Réactions plutôt négatives. En effet ce modèle parait cohérent puisque toutes les problèmatiques 
 liées à la communication client/serveur et au flux de données entre les agents et le serveur seront gérés en un seul point et pourront bénéficier 
 à l'ensemble des clients du service SOAP.

• SNMP.

 Pour l'ipdiscover, l'objectif est de récupérer plus de données sur les matériels réseaux.
 Question: le serveur interroge-t-il directement les matériels réseaux ou les agents font-ils les requêtes?
 Laisser les agents procéder aux requêtes permet de ne pas redéfinir les politiques de filtrage des utilisateurs.
 Durieux a développé un agent pour remonter les infos dans GLPI. Quid de la portabilité sur OCS?
 Il faut prévoir de laisser la possibilité à l'utilisateur de choisir les données qu'il veut remonter.
 Note du rédacteur : la prise en charge des plugins dans ocsreports facilitera l'ajout de la fonctionnalité 
 Il peut être utile de prévoir le scan SNMP de machines déjà inventoriées Ex: oracle sous windows => rien dans le registre.

• Scan de DISQUE DUR.

 Existe déjà dans l'agent windows mais n'est pas appelé. Nécessite l'ajout de la fonctionnalité dans l'agent unifié.
 Précautions à prendre: flux important vers le serveur/cadre juridique.
 Servirait pour la recherche d'un fichier en particulier (recherche d'un logiciel, taille fichier PST, d'une photo, etc.)
 Proposition: avoir un script sur l'agent qui remonte les infos demandées. Il s'agit de la fonctionnalité de lancement de scripts, 
 pas de la recherche sur disque dur à proprement parlé (fonctionnalité intégrée) 
 Il faudrait que cette fonctionnalité soit désactivable. Elle doit l'être par défaut.

• Agent pour terminaux mobiles

 Information à l'assemblé: il existe un agent pour PDA fonctionnant sur le framework OPENMOBILEIS. Les programmes ainsi que la documentation seront 
 prochainement téléchargeables sur le site web. On peut déjà trouver le code source dans le SVN (module mobile_devices).

Schema de base de données

 Présentation et historique de la base de données: schéma "à plat".
 Le format de changement de BDD générera un gros travail d'adaptation du code.
 Aujourd'hui, on pallie les défauts du schéma en fonctionnant avec les tables « _cache » (tables de type)
 Si on migre vers la nouvelle base de données, va-t-on vers un gain important?
 Si le gain n'est pas important, la modification ne sera pas faite. Aujourd'hui cela fonctionne sur 80000 machines...
 Si on modifie de façon partielle, il faut gérer l'exception dans le moteur serveur.
 Il faut faire des tests sur un échantillon pour estimer le rapport coût/efficacité
 Question: portage Postgresql? Bien qu'anciennement envisagé, les ressources disponibles ne permettent pas aujourd'hui d'offrir la compatibilité.

GUI

 Récapitulatif des différentes évolutions prévues. 
  => Architecture de plugins facilitant l'apport de contributions.
  => Gestion des profils, créer ses profils avec les fonctionnalités dédiées.
  => sortie prochaine de la 1.02 et 1.03 RC1 dans la foulée.
 Proposition pour la gestion des langues => utiliser la librairie "gettext". A étudier.

Agent unified

 Récapitulatif de l'historique. 
 Problèmes rencontrés sur l'agent linux.
 Bon pour la 1.02
 Listing des futures évolutions.
 Réécriture de la partie téléploiement. 

Agent Win32

 Problèmes soulevés:
  => Code difficilement maintenable de l'agent actuel.
  => Support des langues non latine pb agent compilé en unicode ok mais pas possible avec win95/98
 Question: doit-on encore supporter les win9x? 
  => Pas de réactions négatives. Si win9x => ancienne version de l'agent. Pour le reste, nouvelle version.
  => OS 64 bit. Question: Faire une version 64 bit?

 Nouvel agent en cours de dev: 
  => réarchitecturé avec système de plugins ne nécessitant pas une recompilation de l'agent (dll) . 
  => Actuellement, seul la capacité d'inventaire est finalisée. 
  => Il faut implémenter le reste des fonctions (télédéploiement et ipdiscover) prévu pour la version 1.1
  => Problème sur le compilateur m$ qui change très souvent. Solution proposée: compilation sous linux avec crosscompil et avec le sdk de windows 
     (ex avec l'agent bakula) – A regarder.

 Support VISTA: 
  => L'agent est compatible mais nécessite du mode débug (problème en cours de résolution).
  => UAC. L'achat de la certification M$ du binaire est très chere.

OCS et les partenaires

• Rappel du sens donné au système partenaire. Demande d'avis au niveau de l'assemblé:

=> le fait de ne pas faire payer permet d'avoir une plus grande liberté.

• Comment exprimer les niveaux de maîtrise des partenaires?

=> Notation par étoile
=> Icones correspondant aux fonctionnalités OCS offertes

• Feedback client.

=> Une interface va être mise en ligne permettant aux clients d'un partenaire d'exprimer son niveau de satisfaction
=> Les formulaires transmis ne seront pas accessibles publiquement.

• Durée du partenariat

=> Candidature testée tous les ans?
=> suggestion: rajouter sur la page du site: "partenaire depuis « date » sur le site"

OCSInventory-ng.org

• Modes de financement du projet

=> Vente sur facture d'un CD ocs : Une explication sur la possibilité d'en obtenir devra être faite sur la page "donation"
=> Hotline téléphonique surtaxée. Cette méthode a déjà été testée par le projet Glpi mais les commissions étaient jugées trop élevées
=> Vente de supports de formation (téléchargeables)
=> Dons: Il faut plus d'incitation. Ex : Inciter au don lors de sortie de la 1.02 ou page sur le site "ils ont donné"

• Les coûts:

=> Réduction des coûts avec le partenariat hébergement 

• Les prochaines manifestations

=> Solutions linux: le projet sera présent sur un stand au pavillon associatif de Solutions Linux 2009
=> Les Rencontre mondiale du libre Juillet 2009 (7 au 11): une conférence sur le télédéploiement sera tenue.

• Prochaine version stable

La sortie de la 1.02 finale aura lieu la semaine 13.