Re: [Glpi-dev] Plugin Additional Reports - Proposition de rapport
Bonsoir, Ce nest pas un bug de GLPI mais bel et bien physiquement que les machines perdent le numéro de série. Dans les raisons il y a par exemple : pas de retag ou mauvais retag après changement de carte mère par le sav, connexion aux ordinateurs en bureau à distance qui dans certains cas provoquent la prêtent des caractéristiques physique, etc etc Donc c'est pour pouvoir suivre tout ça de plus prêt ! -- Thierry BARRAU Envoyé de mon iPhone Le 1 oct. 2012 à 17:11, "David DURIEUX" a écrit : > Peut être que remonter le problème peut être plus utile que faire un > rapport d'un état qui est la conséquence d'un bug? > > David > ++ > > > Le Mon, 1 Oct 2012 16:55:01 +0200 > Thierry Barrau a écrit: > >> Bonjour, >> >> J'ai fait quelques rapports pour les besoins d'un client, mais qui >> peuvent s'avérer utiles pour tout le monde. >> >> Voici le premier : serial numbers changed (testé sous GLPI 0.8.3.4 et >> Additional Reports 1.6.1). >> >> Ce rapport permet de faire une liste de tous les changements de >> numéros de séries survenus entre deux dates, que ce soit pour les >> ordinateurs / moniteurs / périphériques. >> >> Cela fait suite au fait que nous ayons remarqués que les ordinateurs >> en particulier chez HP avaient tendance à avoir le numéro de série qui >> saute de temps en temps. >> >> Cela permet ainsi de vérifier au lieu de tomber dessus au petit >> bonheur la chance. >> >> Je transmettrais les autres dès que je les aurais validés avec les >> dernières versions. >> >> Cordialement, >> Thierry BARRAU >> > > ___ > Glpi-dev mailing list > Glpi-dev@gna.org > https://mail.gna.org/listinfo/glpi-dev > ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Plugin Additional Reports - Proposition de rapport
Peut être que remonter le problème peut être plus utile que faire un rapport d'un état qui est la conséquence d'un bug? David ++ Le Mon, 1 Oct 2012 16:55:01 +0200 Thierry Barrau a écrit: >Bonjour, > >J'ai fait quelques rapports pour les besoins d'un client, mais qui >peuvent s'avérer utiles pour tout le monde. > >Voici le premier : serial numbers changed (testé sous GLPI 0.8.3.4 et >Additional Reports 1.6.1). > >Ce rapport permet de faire une liste de tous les changements de >numéros de séries survenus entre deux dates, que ce soit pour les >ordinateurs / moniteurs / périphériques. > >Cela fait suite au fait que nous ayons remarqués que les ordinateurs >en particulier chez HP avaient tendance à avoir le numéro de série qui >saute de temps en temps. > >Cela permet ainsi de vérifier au lieu de tomber dessus au petit >bonheur la chance. > >Je transmettrais les autres dès que je les aurais validés avec les >dernières versions. > >Cordialement, >Thierry BARRAU > ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Network ports en 0.84
On 01/10/2012 09:42, David DURIEUX wrote: Bonjour, Je me souvient en avoir discuté avec Damien, mais on va poster sur la ML dev. Pour la gestion des ports réseaux, quand on supprime des ports, les networkportnames et ipadresses ne sont pas supprimés de la base. A terme on va avoir des table réellement conséquentes avec des données orphelines... Ne devrait-on pas les supprimer quand on supprime le port? David DURIEUX Bonjour, À l'époque, mon argumentaire et les réponses de David : On 29/07/2012 16:30, David DURIEUX wrote: Le Sun, 29 Jul 2012 16:27:32 +0200 Damien Touraine a écrit: On 29/07/2012 16:11, David DURIEUX wrote: Le Sun, 29 Jul 2012 16:00:06 +0200 Damien Touraine a écrit: Bonjour, Ce n'est pas un bug, mais un feature : un NetworkName peut être détaché de tout entitée le temps d'un transfert sur une autre entitée. Par défaut, lorsqu'on supprime un NetworkPort, tous les NetworkName attachés sont conservés. Cela permet, par exemple, de transférer une adresse IP d'une carte réseau (NetworkPort) à une autre. Pour faire le ménage (supprimer les NetworkName orphelins), il faut aller dans les Noms Réseau (dans les intitulés). Les NetworkName orphelins sont ceux dont l'ID est à 0. On peut changer ce comportement par défaut. C'est à vous de décider. À moins que l'on mette une option pour cela. Ben sur des gros environnement, ça risque de faire une table SQL monstrueuse si on et en ip dynamiques. On peut toujours faire le ménage "à la main". En fait, je suis dans une optique d'utilisation de GLPI sur le mode inventaire ET IPAM, c.-à-d. génération automatique des fichiers de configuration ISC-BIND, ISC-DHCP et mise à jour de la base de donnée FreeRadius (cf. plugin IPAM). Dans ce second contexte, on a souvent besoin de transférer un nom réseau d'une machine à une autre et l'on n'a pas forcément le réflexe de transférer l'adresse IP sur la nouvelle machine avant de supprimer l'ancienne. C'est pour cela que j'avais mis en place ce comportement. Ouais mais il vaut mieux recréer l'ip par exemple plutot que de laisser des données non associéee. Si les ip se baladent d'une machines à une autre on va arriver à vraiment beaucoup d'enregistrement qui ne serviront à rien (dans la table glpi_ipaddresses par exemple) et j'ia peur que ça génère des soucis derrière. Après faut voir avec les autres dev voir ce qu'ils en pensent ;) Comme je l'indiquais, si vous préférez, ce comportement par défaut peut être modifié, a priori, par l'ajout de deux lignes dans NetworkPort::cleanDBonPurge(). Damien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] Network ports en 0.84
Bonjour, Je me souvient en avoir discuté avec Damien, mais on va poster sur la ML dev. Pour la gestion des ports réseaux, quand on supprime des ports, les networkportnames et ipadresses ne sont pas supprimés de la base. A terme on va avoir des table réellement conséquentes avec des données orphelines... Ne devrait-on pas les supprimer quand on supprime le port? David DURIEUX ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
