Chef dr projet NTIC - Direction Régionale AFPA Bretagne a écrit :
GlacierJe crois qu'il y a grand danger à inclure une gestion des services
dans GLPI.... sans avoir précisément défini et pris en compte cette notion
en rapport non pas avec les besoins d'untel ou d'untel (il y en aura
tellement de différents que je ne vois guère comment les sérier), mais
plutôt avec une approche reposant la compréhension partagée de ce qu'est un
service.
La dessus nous sommes totalement d'accord, d'ou le débat actuel alors
que le patch est déjà fait et, à priori, correct techniquement parlant
(au niveau du code).
Comme le disait Julien, nous essayons (et c'est la dessus que nous
perdons le plus de temps) de garder un modèle conceptuellement correct.
Malheureusement, mais ça c'est du à l'histoire de GLPI, nous n'avons pas
conçu le modèle de départ, malgré tout nous essayons au maximum de
garder un modèle cohérent et évolutif lors des ajouts de fonctionnalitées.
Sur le cas particulier des services, c'est un contributeur extérieur
qui, pour ses besoins internes, à décidé d'en prendre la responsabilité
et qui à réalisé un patch, alors que nos discutions sur la façon de
l'implémenter avait viré au dialogue de sourds.
Comme je l'ai déjà dit nous ne sommes pas d'accord avec l'auteur du
patch sur la façon d'implémenter ça, et particulièrement au niveau du
modèle.
Pour nous, séparer les services des logiciel, est une aberration
conceptuelle et sera la source de gros ennuis si l'on veut faire évoluer
le tout.
Ce que l'on appelle service, c'est par exemple : le service http (ou
serveur web), le service smtp (ou serveur de messagerie), etc.
Pour moi smtp et http ce sont plutôt des protocoles utilisés dans des
services.
Globalement les informations supplémentaires que l'on a à gérer sont :
- Une liste de services "connus" comprenant :
- Un nom.
- Un protocole.
- Un port d'écoute par défaut.
Connus de qui ? Si c'est la liste des services standards (cf. /etc/services)
il ne sert à rien de les gérer. Si c'est du gestionnaire GLPI, ok.
"Un nom" ? C'est quoi par exemple ? Pouvez-vous préciser
"Un protocole" ? c'est quoi là aussi ? UDP ou TCP ? ou smtp ou http ?
"Un port" ? Oui mais c'est insuffisant. Pour certains de nos serveurs il est
nécessaire de spécifier les interfaces sur lequel il est autorisé en écoute,
et pas seulement le port. Le service n'est pas forcément actif sur tous les
interfaces.
Dans les cas que nous administrons ce que je peux dire c'est que :
- il y a toujours derrière - ou plutôt à l'origine - du service une
application (à ce titre les "services" nous semblent plutot des attributs de
certaines applications)
- cette application peut dialoguer en utilisant un ou plusieurs "service"
avec d'autres applications
- chacun de ces "services" utilise un port, les protocoles UDP et/ou TCP, un
protocole genre smtp, http, ntp,etc. et un ou plusieurs des interfaces
réseaux dont dispose la machine
- le même "protocole" genre http peut évidemment être actif plusieurs fois,
sur des port différents, lancés par la même application ou des applications
différentes (genre un apache avec 3 instances simultanément avec un Plone)
Nous avions présenté ça de manière assez simpliste (on va dire globale)
dans le mail, en enumérant les principaux concepts qui entraient en
oeuvre sans entrer dans le detail (le débat ne se situant pas à ce
niveau de granularité).
Nous partons du principe que si l'on part sur un modèle général sein, il
sera facile de le faire évoluer.
Ceci dit vos remarques sont pertinentes et il y a des points que l'on
avait pas envisagé, que l'on va s'empresser de noter.
Plus j'y pense et plus j'ai l'impression que tout part des applis.
Justement c'est là le centre du débat, est ce que l'on décrette que les
services sont complétement indépendants par rapport aux
logiciels/applications ce qui est faux d'un point de vue conceptuel.
Ou est ce que l'on essaye d'avoir un modèle conceptuellement correct,
qui sera (selon nos avis) beaucoup plus facile à faire évoluer, même si
cela complexifie les manipulations sur les données.
Pour moi la question ne devrait même pas se poser...
--
Bazile Lebeau
