Apps – iTOP

Comme je vous l’ai sûrement déjà dit ou si vous l’avez déjà lu, j’ai dans mon expérience personnelle et professionnelle été confronté au monde du service. Qui dit service dit prestation de service et donc retour sur cette prestation.

Il existe la norme ISO 9001 visant à mettre en place un système de management de la qualité dans l’objectif de mesurer et d’améliorer en continu la satisfaction des utilisateurs. L’inconvénient d’une norme est que cette dernière doit être renouvelée tous les trois ans et nécessite de passer par un audit externe pour être de nouveau recertifié. Pour obtenir la certification, il est nécessaire d’embrasser la norme dans sa totalité et ce même si seulement un toute petite partie vous intéresse ou vous concerne.

En comparaison il existe ITIL¹. ITIL est presque comparable à la norme ISO 9001. Toutefois, il s’agit d’un ensemble de bonne pratiques et est adapté pour le management des systèmes d’information. Nous retrouvons la notions de KPI², de niveau d’engagement, de qualité de service etc. Etant un ensemble de bonne pratique il est donc possible contrairement à la norme ISO 9001 de sélectionner se qui est indispensable pour l’activité de notre organisation.

Niveau certification cette dernière est portée par les hommes et non par la société sans échéance de validité. Il existe plusieurs niveau de certification.

Si je vous parle de ces deux notions, c’est que je souhaiterai vous présenter une solution opensource ITSM³ (construit sur l’une des bases ITIL), incluant une CMDB⁴. Je vous parle d’ITOP, de Combodo.

J’ai rencontré cette solution en 2014 lorsque j’étais un jeune « trou du cru » sur le marché du travail. Cette solution était utilisée par la société pour gérer au quotidien le parc informatique, les requêtes utilisateurs, les enquêtes de satisfaction et à l’époque le MCO⁵ afin d’être pro-actif afin d’éviter de potentiel incident d’infrastructure.

Bref, cette solution me permet de garder un peu la forme côté GNU, en pratiquant mon bash et me remettant en cause en permanence quant à la sécurité et la bonne gestion des systèmes LINUX. Mais également comme cette solution gère les tickets de créer des passerelles entre des applications tierces (SPOILER, ça sera dans d’autres articles).

Dans cette article, je souhaite partager avec vous mon retour d’expérience sur le déploiement d’ITOP (Community ce qui entre nous ne change rien de la version Essential ou Entreprise pour ce que fait sur mon temps libre) sur une architecture 2-Tiers durcie.

Point important, j’ai pour habitude de ne travailler qu’avec des versions LTS⁶ et non STS⁷ (ça c’est juste pour le fun). Donc à ce jour, la dernière version LTS et la 2.7. C’est cette version que je déplorerai.

Le schéma topologique ci dessus représente l’infrastructure que nous allons mettre en place. Ce schéma sera amené à évoluer en vu des projets à venir.

Dans la logique, il devrait y avoir publication. Malheureusement, mon lab à domicile, possède certaines contraintes :

• Absence de Firewall
• Absence de hyperviseur ayant suffisamment de ressource pour faire tourner l’ensemble de mon lab
• Absence d’IP Public fixe
• Absence d’équipement physique ou virtuelle pour réaliser de la micro segmentation (nous ferrons à l’ancienne).
• Faible débit, 100 Mbits/s. Blague mise à part, il n’y a pas si longtemps j’avais une ADSL 10Mbits/s. Donc pas si faible que ça. 🙂

Ce n’est pas grave, chaque chose en son temps. La publication n’est pas le point le plus ardu du déploiement.

Prérequis

• SE : RHEL
• Apps : ITOP, APACHE, MariaDB
• Autres : LINUX – Durcissement GNU, Recommandation ANSSI, ITOP (documentation)

Installation et Durcissement du SE

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article LINUX – Durcissement GNU, Recommandation ANSSI .

Je pars du principe que le durcissement a été réalisé. Si ce n’est pas le cas, vous pouvez suivre directement la documentation de l’éditeur pour le déploiement.

/!\Attention : Il est fort probable suivant votre durcissement que vous rencontriez des erreurs que je n’aurai pas et inversement. Ainsi il est possible, que les points bloquants que je vais rencontrer ne soient pas présent de votre côté. M’enfin, This is the law !

Concernant les recommandations matérielles (physiques ou virtuelles), vous retrouverez les préconisations ci-dessous de l’éditeur

Pour ce qui est des préconisations des composants et dépendantes logicielles

Backend

Je recommande toujours dans le cadre des serveurs de base de données de dédié un disque pour le SGBD⁸ et un disque pour réaliser les dumps de ou des bases de données.

Dans notre cas, nous allouerons un disque de 20Go pour le SGBD et un disque de 20 Go pour nos dumps.

Dans le respect des bonnes pratiques GNU, je crée deux répertoires sous /mnt

• databases
• dump

$ sudo mkdir /mnt/databases
$ sudo mkdir /mnt/dump

Il est nécessaire d’avoir préalablement créé les partitions et monté ces dernières en xfs.

Pardon, M’sieur, mais moi je débute avec Linux. Vous pouvez me dire comment qu’on fait, c’est pas plug and play ? On m’appelle le chevalier blanc, je vais et je vole au secours d’innocent…. Bref c’est un basique, mais n’avons nous pas tous commencé par là ? Je vous invite à parcourir la section déjà documentée dans l’article LINUX – Disk & Part.

Mariadb – Installation

Si vous êtes sur un environnement durci, avant de lancer les installations il y a quelques choses à faire, sinon vous allez être marron 🙂

Il est nécessaire dans le cas de notre version d’ITOP de déployer la version 10.6 de MariaDB. Toutefois, j’ai décidé pour des raisons pratique de faire un article dédié sur l’installation, configuration et sécurisation du serveur MariaDB. Je vous invite à vous référer à ce dernier dans l’article Apps – MariaDB.

iTOP – Configuration

L’installation, configuration et sécurisation étant terminée, nous allons enfin aborder le sujet ITOP côté BDD.

Il est à noter que nous pouvons sécuriser d’avantage ITOP en implémentant la couche SSL entre notre serveur web (front) et notre serveur BDD (back). Nous aborderons dans une section singulière cette fonctionnalité optionnelle.

Les opérations SQL se déclinent en cinq mouvement comme une symphonie fantastique.

Nous pouvons quitter la console SQL. La configuration d’ITOP est terminée pour la partie BDD. Pour le reste, il faudra attendre la configuration du front end et le lancement de la toute première instance de wizard ITOP.

N’oubliez pas également que le port SQL doit être ouvert sans quoi votre server refusera les flux entrant sur le port 3306/tcp.

$ sudo firewall-cmd --permanent --add-port=3306/tcp
$ sudo firewall-cmd --reload

Frontend

Installation des Dépendances

Si vous êtes sur un environnement durci, avant de lancer les installations il y a quelques choses à faire, sinon vous allez être marron 🙂

Nous allons attaquer l’installation de la partie web. Toujours en adéquation avec les prérequis logiciels pour la version 2.7.9. Avant toutes choses, mettons à jour notre système.

# dnf update

Et nous voila emmerdés. Notre gestionnaire de paquet connait bien les paquets php que nous souhaitons mais dans leurs dernière version 8.X. Sauf que nous voulons la version 7.4… Chaque problème, sa solution.

Nous allons ajouter le repo Remi à notre système fournit par Fedora. Si nous nous rappelons l’un des point de recommandation de l’ANSSI, sommes nous à 100% sure de ce repo ? La réponse est oui. Ce repo est gérée par une communauté Fedora pour la gestion des paquets PHP en version 7 et 8. Fedora étant un système RHEL nous sommes donc compatible. Néanmoins il est important de noter qu’il viendra prendre l’ascendant sur les paquets PHP fournit par le système.

Ajouter le repo Remi.

# dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm

Regardons les versions disponibles de php et celles disponibles et actifs sur notre SE

# dnf module list php

Le retour est explicit, la version qui fait foi est la version 8.1 du repo system (AppStream). Installons donc en lieu et place la version qui nous intéresse, la 7.4.

# dnf module install php:remi-7.4

Installons les dépendances nécessaires en prenant garde à la version des modules php que nous allons installer afin que ces derniers sont bien dans la version attendu. Sinon c’est un peu con.

# dnf install php php-zip php-mysqlnd php-mcrypt php-xml php-cli php-soap php-ldap php-gd mod_ssl graphviz php-pear-Net-Socket php-imap

Ajoutons le daemon httpd comme service à lancer automatiquement au démarrage (sinon c’est con va falloir le faire manuellement si la bécane va reboot comme pour la SGBD).

$ sudo systemctl enable httpd

Ajouter les règles de firewall pour ouvrir les ports 80/tcp et 443/tcp.

$ sudo firewall-cmd --permanent --add-port=443/tcp
$ sudo firewall-cmd --permanent --add-port=80/tcp
$ sudo firewall-cmd --reload

Créons sous /var/www/html/ le répertoire qui va contenir l’ensemble des ressources ITOP. Le nom est libre (mais nous allons tacher d’être cohérent), attention toutefois de garder ce dernier de côté car le path sera utilisé dans le fichier de configuration ci-bas. Nous reviendrons quelques lignes plus bas sur l’installation.

$ sudo mkdir /var/www/html/portail.erwanguillemard.com

C’est presque terminée. Il ne nous reste plus qu’a déployer ITOP. Toutefois il nous reste à configurer notre serveur Apache et sécuriser ce dernier.

Apache – Configuration

La configuration est nécessaire pour publier et accéder à notre serveur web.

Intrinsèquement, va se jouer la sécurisation du serveur WEB à travers les aspects tels que la redirection de port http vers https, la mise en place d’un certificat, prévention de man in the middle, ect.

Pour le coup, le travail est déjà fait par l’éditeur. Et ça nous n’allons pas nous plaindre ! Pour un fois, c’est plaisant d’avoir un éditeur de solution applicative qui ne laisse pas ces utilisateurs sans directives précises. Je trouve également que cela marque considérablement l’implication de COMBODO vis à vis de ces utilisateurs, de sa communauté et de l’importance des données qui pourraient être contenu dans la, les bases de données ITOP. Lien

Editer un nouveau fichier sous /etc/httpd/conf.d/ pour rester cohérent, il est de bonne pratique de donner en nom de fichier le sous-domaine (quand il y en a un) suivi du nom de domaine et de l’extension avec l’extension conf. Ainsi, dans le cas de modification de la configuration le risque d’erreur de fichier est restreint (du moins normalement).

$ sudo vim /etc/httpd/conf.d/portail.erwanguillemard.com.conf

Editez le fichier comme ci-dessous, bien que je ne suis pas familier des configurations WEB (désolé, un traumatisme durant mes études…) je vais expliquer autant que faire se peux ma configuration. Toutefois et comme énoncé précédemment, c’est à vous d’adapter les valeurs (nom et chemin hein).

• <IfModule mod_ssl.c> : Vérifie que le module est bien présent, sans quoi la configuration qui suit ne sera pas appliquée. Normalement, le module est présent de base dans le package d’installation par défaut de httpd.
• <VirtualHost *:443> : Indique que notre serveur écoute sur toutes les IPs uniquement sur le port 443
• SSLEngine on : Précise que nous allons utiliser du chiffrement SSL
• SSLCertificateFile : Indique le fichier .crt ou .csr qui va servir au chiffrement des requêtes HTTP
• SSLCertificateKeyFile : Indique le fichier .key qui va servir à déchiffrer les requêtes HTTPS
• SSLCertificateChainFile : Permet de retourner la chaîne de certification lors des connexions HTTPS. Commentée dans mon cas car je n’ai pas de certificat et passe donc par un autosigné

/!\ Attention : Concernant ces trois lignes, je vous recommande si vous n’êtes pas à l’aise avec la génération de certificat ou manipulation d’openssl de suivre l’article LINUX – Certificats.

• ServerName : Le nom qui sera utilisé par le virtualhost pour que le serveur puisse s’authentifier
• DocumentRoot : L’emplacement de notre site web
• <Directory Path> : Définit les options et paramètres pour le site dont nous avons spécifié le chemin
• Options -Indexes -FollowSymplinks : Autorise l’indexation des répertoires ainsi que l’exécution des liens symboliques contenu dans ce dernier
• AllowOverride All : Prend en compte les directives présents dans le fichier .htaccess
• Order allow, deny : Définit l’ordre de traitement des règles. Ici les règles seront acceptées avant les règles refusées répond favorablement aux règles et se vera alors autorisé l’accès.
• Allow from all : Autorise l’accès sans restriction

Dans l’état, notre fichier de configuration est correct. Nous sommes donc pret à publier notre appliance si les sources étaient présent dans notre répertoire.

Néanmoins, il manque deux points cruciaux. Le premier est comme toujours dans notre environnement durci la configuration du SELinux. Le second point, comme évoqué plus tôt concerne la sécurisation de notre instance ITOP à travers les recommandations de l’éditeur quand aux daemon apache ainsi que le moteur php.

Bien, reprenons donc là où nous en étions.

Le SELinux étant actif, il va être nécessaire d’autoriser notre bon vieux démon apache à joindre le réseau, les bdds à travers le réseau et de définit les contextes d’exécution.

$ sudo setsebool -P httpd_enable_homedirs on
$ sudo setsebool -P httpd_can_network_connect_db 1
$ sudo setsebool -P httpd_can_network_connect on
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/portail.erwanguillemard.com

Apache & PHP – Sécurisation

De mon point de vu personnel ce point bien que facultatif est à implémenter. Jusqu’à présent je ne m’étais jamais penché sur le sujet. Le web m’aillant traumatisé, tant que c’est fonctionnel ça m’allait très bien. De nos jours, nous ne pouvons pas nous permettre de faire l’impasse sur la sécurité et comme nous avons déjà les recommandations et préconisations de l’éditeur, pourquoi se priver ?

Je ne compte pas reprendre en détails toutes les recommandations, les instructions sur le site officiel (rappel du lien) sont plus qu’explicites.

Apache

PHP

Comme résumé par COMBODO, par défaut, le moteur PHP à un certains nombre de paramètres qui peuvent (doivent ?) être durci. L’ensemble des modifications seront à réaliser dans le fichier /etc/php.ini

$ sudo vim /etc/php.ini

ITOP – Installation

Créons sous /var/www/html/ le répertoire qui va contenir l’ensemble des ressources ITOP. Le nom est libre, attention toutefois de garder ce dernier de côté car le path sera utilisé dans le fichier de configuration ci-bas.

$ sudo mkdir /var/www/html/portail.erwanguillemard.com

Télécharger le paquet d’installation 2.7.9. Deux possibilités s’offrent à nous :

• Télécharger directement l’archive depuis le serveur front
• Télécharger depuis une machine tierce puis transfert en SSH (scp ou sftp)

Personnellement, j’ai tendance à utiliser la première méthode. Tout dépendra de mon humeur et surtout du contexte de sécurité. Dans les deux cas, un contrôle de l’empreinte est nécessaire.

$ wget https://sourceforge.net/projects/itop/files/itop/2.7.9/iTop-2.7.9-11939.zip/download

$ sha1sum /home/adm.r-one/download

Le cas présent, l’empreinte est identique, nous pouvons poursuivre le déploiement. Créer un répertoire temporaire puis décompresser l’archive.

$ mkdir iTop
$ unzip download -d iTop
$ ls -al iTop/ 

Copier l’intégralité du contenu du répertoire web dans le répertoire créé plus tôt sous /var/www/html/<mon_site>/.

$ sudo cp -R iTop/web/* /var/www/html/portail.erwanguillemard.com/

Modifier les droits sur l’ensemble du répertoire sous /var/www/html/<mon_site> afin d’autoriser l’utilisateur ainsi que le groupe apache à opérer. Puis autoriser le contexte SELinux pour que le daemon httpd puisse écrire dans notre répertoire web.

$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/portail.erwanguillemard.com

Nous allons pouvoir lancer le wizard.

iTOP – Instanciation

Dans un navigateur rendez-vous sur l’url https://votre_url/setup. Cela fonctionne également avec l’IP, mais SPOILER ALERT, vous allez avoir une surprise durant le déploiement (à la suite de notre configuration) 🙂

Si vous ne publiez pas votre ITOP et que vous êtes en situation de lab, vous pouvez remédier à cette situation avec une petite surchage DNS dans votre fichier host ou alors un enregistrement de type A dans votre serveur DNS. Pour la première option, ce n’est pas bien catholique, mais c’est pour le bonne cause, c’est pour du test.

Bien, nous voilà au terme de notre article, nous voici sur un ITOP tout propre, tout beau et vide. Mais l’appliance est opérationnelle et c’est là bien l’objectif que nous nous sommes fixé en début de ce billet.

Pop pop pop garçon ! Tu vas pas planter tes lecteurs comme ça ? Oui j’ai oublier d’aborder quelques points.

Premièrement, oui notre instance est vide et il va falloir configurer cette dernière. Pour la faire courte, je vais faire un article dédié car cela risque de faire de long.

Secondement, il reste quelques petites configurations dont l’une des plus importantes, l’exécution des tâches en background, les notifications ect. Je vous propose d’aborder ces quelques points dans les sous parties ci-dessous.

ITOP – Paramétrage du cron

Je vais reprendre ce que j’ai l’habitude de faire de mon côté, vous retrouverez en détails l’ensemble des actions sur le site de l’éditeur (Lien).

Connectons nous à notre appliance dans un navigateur web (https://portail.erwanguillemard.com/pages/UI.php) avec le compte admin et ajoutons un nouvel utilisateur (Administration>Compte Utilisateur) interne à ITOP. Créer une nouvelle personne, puis compléter la fiche de contact en spécifiant le profil Administrator (cf les deux captures ci-dessous). Gardons bien à l’esprit que les noms doivent être parlant pour faciliter le MCO de notre application.

Une fois l’utilisateur créé, connectons nous sur notre serveur front en ssh.

/!\ Attention : Il est préconisé par l’éditeur de ne pas garder le fichier de paramètre du cron dans le répertoire web car ce dernier contient des informations sensibles (login et mdp) mais de le stocker à un autre emplacement. Je rencontre actuellement une frustration sur ce point car il n’est pas opérant sur mon environnement FRONT durci. Après deux nuits de diagnostics, je vais mettre de côté cette recommandation et poursuivre les investigations en parallèle.

Les deux fichiers nécessaires aux taches en arrière plan seront stockés dans le répertoire web sous /conf/itop. Nous allons donc créer ce répertoire, lui appliquer les droits et saisir le contenu du fichier cron.params. (Naturellement, vous adapter les chemins ainsi que les noms de fichiers 🙂 )

$ sudo mkdir /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo vim /var/www/html/portail.erwanguillemard.com/conf/itop/cron.params

Faisons de même avec le fichier cron.sh. Notez que dans le script bash, nous réorientons les flux de sortie dans un fichier de log. Il est nécessaire d’adapter les droits en conséquence. Je vous recommande également d’appliquer une stratégie de rotation des logs avec logrotate. Effectivement et par expérience, le fichier de log va grossir autant que le nombre de données et d’utilisateur sur votre appliance. Si vous ne voulez pas saturer votre espace de stockage, vous savez quoi faire.

$ sudo vim /var/www/html/portail.erwanguillemard.com/conf/itop/cron.sh

Auparavant dans les premières version d’ITOP que j’ai manipulé, les tâches planifiées (cron) étaient lancés en tant que root. Avec le temps, (va tout s’en va…) il est de bonne pratique de ne pas utiliser le compte root pour des applications et d’utiliser ce dernier avec parcimonie. C’est pourquoi toujours en suivant les recommandations de COMBODO, nous allons réaliser ces tâches avec l’utilisateur apache.

J’aime dans un premier temps afficher l’ensemble des tâches exécutés par l’utilisateur puis j’ajoute la nouvelle tâche. Pour le bien de l’application il est recommandé d’exécuter la tâche toutes les 5 minutes. (Alors pourquoi tu as mis 6 ? Je sais pas, peut être parce qu’il n’est pas premier ? 🙂 )

$ sudo crontab -u apache -l
# crontab -u apache -e

Nous réappliquons les permissions ainsi que les acls sur nos deux nouvelles ressources. L’objectif étant de sécuriser au maximum le contenu de ces deux fichiers.

$ sudo chown apache:apache -R /var/www/html/portail.erwanguillemard.com/conf/itop
$ sudo chmod 750 //var/www/html/portail.erwanguillemard.com/conf/itop/cron.sh
$ sudo chmod 640 /var/www/html/portail.erwanguillemard.com/conf/itop/cron.params
$ sudo systemctl restart crond

Pour débugger et ou contrôler la bonne exécution des tâches planifiées, nous pouvons utiliser la commande ci-dessous pour lancer manuellement les tâches. Nous pouvons également contrôler le contenu du fichier de log. En cas de dysfonctionnement, soit vous n’avez aucun retour ou des erreurs.

Dans certains cas, le cron est fonctionnel mais « planté ». L’exécution des tâches de fond étant réalisées de manière procédurale, si une tache se retrouve en carafe, les autres tâches resteront en attente. L’identification de l’incident sera plutôt facile car les compteurs des prochains « run » seront antérieur à la date de la dernière exécution.

$ sudo php /var/www/html/portail.erwanguillemard.com/webservices/cron.php --auth_user=service.itop --auth_pwd='yS=>LMuN>5OrzvW2{Qj.' --status_only=1
ou
$ sudo tail -f /var/log/itop_cron.log

ITOP – Notifications

Promis ensuite notre environnement sera opérationnel et nous n’aurons plus qu’à peupler notre application et donc notre base de données. Toutefois, notre solution de ticketing doit envoyer des notifications mails pour les échéances des CIs, le cycle de vie des requêtes, les dépassements des SLAs, TTRs etc. De base, ITOP utilise la fonction PHPMail sauf que pour des raisons de sécurité je préfère passer par un relai SMTPS.

Dans iTop la configuration est plutôt simple et la documentation aussi clair que de l’eau de roche, il suffira de suivre le wiki et de lire les commentaires du fichier de configuration générale. A ce niveau il y a deux moyens possible :

• Web : Sous Configuration > Configuration Générale (si profil admin)
• CLI : Sous /var/www/html/<site>/conf/production/config-itop.php

Pour des raisons pratiques, vous conviendrez que l’interface en WEBUI va nous faciliter les choses, alors pourquoi se priver ?

Dans mon cas, je commente la ligne par défaut PHPMail pour remplacer la valeur par SMTP puis implique la configuration comme suit.

Variable	Type	Valeurs et commentaires
email_transport	String	SMTP
email_transport_smtp.encryption	String	TLS ou SSL, champ optionnel qui permet d’activer le chiffrement sur le protocole SMTP.
email_transport_smtp.host	String	Mon relai smtp (ovh dans mon cas), par défaut si la variable n’est pas renseignée dans le fichier de configuration l’hote utilisé par le serveur SMTP sera la machine elle-même (localhost). Champ optionnel.
email_transport_smtp.password	String	Le fameux mot de passe des familles pour s’authentifier sur le serveur SMTP (host) renseigné ci-dessous. Champ optionnel.
email_transport_smtp.username	String	Le compte servant à s’authentifier sur le serveur SMTP (host) renseigné ci-dessous. Champ optionnel.
Email_transport_smtp.port	Integer	Le port à préciser pour envoyer les notifications. par défaut si la variable n’est pas renseignée dans le fichier de configuration le port utilisé sera le port 25.

Une fois la configuration effectuée, cliquez sur le bouton enregistrer en haut de la page. Si vous avez une erreur de syntaxe, ITOP qui est bien sympa vous l’indiquera.

Pour tester si notre configuration à travers notre relai SMTP fonctionne bien, utilisons la fonctionnalité mise à disposition sous https://site/setup/email.test.php

Conclusion

L’une des grandes questions que vous pourriez me poser, c’est pourquoi tout ce cirque pour installer ITOP ? Question purement légitime. La première raison, est une raison de cœur. Cette solution m’a accompagné au tout début de vie professionnelle comme SysAdmin et représente la clé de voute du service que l’IT délivre au quotidien tout en garantissant un bon suivi du parc informatique. La seconde est non des moindres, la solution est OpenSource. Nous pouvons donc mettre les mains facilement dans le moteur et se salir le bout des doigts en faisant « évoluer » la solution à notre convenance, au besoin des organisations et des ces utilisateurs.

En l’occurrence, j’ai un certain nombre de module qui viennent compléter ITOP pour en faire MON ITOP. Ces derniers pourraient satisfaire la communauté, pourquoi pas ? Je me suis donc dit que la première fondation de cet édifice devait passer par l’installation d’ITOP. Je pense également continuer quelques plus petits articles comme l’upgrade d’une instance existante ou autres.

Et sinon, tu parles de module, tu la craches ta VALDA ? C’est un pop up HELLO WORD ?

Dans les articles à venir, je souhaite partager mon expérience sur :

• Un petit plugin d’administration en bash d’ITOP (front)
• Un plugin de réalisation de dump de la BDD sur un certain nombre de point de rétention en mode service en bash (back). Indépendant de ce qui est actuellement présent dans ITOP
• Un plugin d’externalisation de la BDD ITOP sur un autre site en bash
• Un gros plugin (presque une passerelle) d’intégration de suivi de sauvegarde entre la solution VEEAM (Service Provider Console et Data Plateform) et ITOP en powershell

Le monde du libre n’a pas de limite tant qu’il y aura du partage et une communauté pour faire vivre les solutions. ITOP et COMBODO s’inscrivant en plein dans cette ligné.

Le mot de la fin :

Je VEEAMZip mes serveurs ITOP et tente l’upgrade avec Jacques TOUBON ? Vous ne pouvez pas le C: est full. Vous tombez en case SYNERBOX et vous devez appliquer la loi AllGood.

Erwan GUILLEMARD

Sources

• ISO 9001
• ITIL
• ITOP
• ITOP – Secure your ITOP
• Mariadb – Repo
• Remi – Repo (PHP 7.4)

1. ITIL, Information Technology Insfrastructure Library ↩︎
2. KPI, Key Performances Indicators ↩︎
3. ITSM, Information Technology Service Management ↩︎
4. CMDB, Configuration Management DataBase ↩︎
5. MCO, Maintient en Condition Opérationnel ↩︎
6. LTS, Long Time Support ↩︎
7. STS, Small Time Support ↩︎
8. SGBD, Système de Gestion de Base de Données ↩︎