Petite astuce, toujours dans l’écosystème Elasticsearch avec lequel je joue pas mal en ce moment…

J’ai pas mal galéré à créer un mapping personnalisé pour importer des données via un river JDBC (GLPI Dashboard), mes champs strings passaient automatiquement en « analyzed » et pour jouer avec dans Kibana, c’est pas la joie…

Je me suis rendu compte que quand on utilise logstash, par défaut il detecte automatiquement les champs, et pour ceux qui sont « analysés », il ajoute un « champ.raw » qui contient la donnée brute. J’ai donc cherché un peu de ce côté là et j’ai vu qu’il était possible de créer des templates de mappings en fonction des index!

Lire la suite de

Petit retour sur le précédent article GLPI-Dashboard :

EDIT : Nouvel  article, automatiser le paramétrage et la communication entre ES et GLPI : Kibana pour GLPI en 15 minutes!

Après avoir pas mal joué avec Kibana et les données en provenance de glpi je me suis rendu compte qu’il y avait pas mal de truc qui manquaient pour avoir des infos fiables et utilisables.

On va donc voir ici comment améliorer tout ça, et avoir encore plus de matière pour jouer!

1/ Les Demandeurs et Techniciens :

Dans la vue MySQL je remonte les champs users_id_recipient et users_id_lastupdater, concrètement ça récupère le nom de la personne qui ouvre le ticket et le nom de la dernière personne qui l’a modifié, les champs « Par » et « Dernière modification ».

glpilastupdater

Au début il m’a semblé pouvoir fonctionner comme ça, par souci de simplicité (voir de flemme 🙂 ), étant donné qu’une bonne partie de mes utilisateurs ouvrent leurs tickets  par mail, via un collecteur IMAP, ils sont donc identifiés comme « recipient », même combat pour les techniciens, ils sont généralement les derniers à modifier le ticket et donc considérés comme « lastupdater ».

J’ai vite déchanté!

Lire la suite de

Dans la lignée des précédents articles sur la mise en place d’un dedié OVH Hyper-V Server et l’administration de ce dernier on va voir ici comment installer une VM pfSense et la paramétrer avec une IP Failover.

On commence par récupérer l’ISO et créer une nouvelle VM de génération 1, J’ai mis 4x core, 512 de RAM et 8gb de vhdx.

Une fois la VM créé on ajoute les interfaces réseaux dont on à besoin. Bien penser à inscrire l’adresse MAC statique de l’IP Failover dans les paramètres avancés de l’interface wan (vSwitch externe).

Lire la suite de

On a vu dans un précédent article comment se dépatouiller avec un serveur dedié OVH fraîchement sorti du carton et Hyper-V Server R2 (qui n’a pas d’interface graphique). On à sur le serveur dedié une VM en 2012 R2 standard connectée sur le vSwitch externe (bridge wan) avec une IP Failover et un accès TSE ou console (5nine) actif. On veut maintenant pouvoir gérer notre Serveur via les outils d’admin distants.

Lire la suite de

Ohlala, encore une galère…

J’ai perdu une bonne partie de ma journée (soirée?) sur cette histoire, je dois être vraiment mauvais.

Je résume la situation, serveur dédié OVH fraîchement loué, Comme OS on à de l’Hyper-V Server 2012 R2, ne contient que le rôle Hyper-V sans interface graphique (version gratuite).

Une fois le serveur provisionné et installé via l’interface d’administration, je reçois par mail les infos de connexions. Connexion TSE sur la machine pas de problèmes tout va bien. Je commence donc à regarder comment je pourrais administrer tout ça, notamment via les outils d’administrations distants.

Lire la suite de