La gestion de parc informatique – Partie 1 : OCSInventory

Propriétés Description
Type de publication Côté labo
Intitulé cout Inventaire et gestion d'un parc informatique
Intitulé long Automatisation de l'inventaire d'un parc informatique avec télé-
déploiement d'application
Version V3.0
Module BTS SIO2 – SI7 – Intégration et adaptation d’un service
Transversalité SISR3 : Exploitation et sécurisation des services Web
SISR4 : déploiement d'applications
Présentation L'objectif de ce Coté Labo est de simuler, dans la salle laboratoire réseau, la
gestion d'un parc informatique qui comprend la collecte automatisée
d'éléments, une première gestion de ces éléments ainsi que le télé-
déploiement d'applications.

Il se place dans un contexte de lycée et utilise une base de données initiale.

Ce travail peut constituer une première introduction aux processus ITIL

(Information Technology Infrastructure Library) de gestion des configurations
des services informatiques.
Activités D5.1 – Gestion des configurations
• A5.1.1 Mise en place d’une gestion de configuration
• A5.1.2 Recueil d’information sur une configuration et ses éléments
• A5.1.3 Suivi d’une configuration et de ses éléments
Pré-requis Avoir quelques notions sur l'installation, la configuration et l'administration
d'un serveur Linux (ou Ubuntu).
Exploitation des services Web et bases de données.
Savoir-faire En SI7 :
principaux • installer et configurer un outil d’inventaire et de gestion des
configurations
• Automatiser l'installation d'un service
• Justifier le choix d’une solution de mise en production d’un service
• Valider et documenter la mise en exploitation d’un service
Savoir-faire En SISR3
transversaux • Sécuriser un service
• Administrer un service
• Analyser le contenu des fichiers d'activité, d'audit et les indicateurs de
métrologie
EN SISR4
• Automatiser une tâche d'administration
EN SI3 (consolidation)
• Extraire et modifier les données d’une base de données
En SLAM 5
• Justifier le choix d'une architecture applicative

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 1/29

Prolongements En SI7 :
• Installer un outil complémentaire de gestion des configurations
• Installer et configurer un logiciel de gestion d’incidents
• Évaluer la valeur actuelle d’un élément d’une configuration
• Évaluer l’impact financier de la consommation d’un service
• Élaborer une procédure de remplacement ou de migration d’un
élément d’une configuration
• Sauvegarder et restaurer une base de données
• Réfléchir aux stratégies et techniques associées à la continuité du
service rendu

En SISR3 :
• Caractériser les éléments nécessaires à la qualité, à la continuité et
à la sécurité d'un service
• Installer et configurer les éléments nécessaires à la qualité et à la
continuité du service
• Assurer la mise à jour d’un service
• Valider et documenter la qualité, la continuité et la sécurité d'un
service

En SISR5 :
• Installer et configurer une solution de contrôle et de surveillance des
communications

En SLAM4 :
• Programmer et/ou adapter un composant logiciel (développer ou
adapter un plugin OCSInventory)

En SLAM5 :
• Valider et documenter une solution applicative
Outils Serveur Linux Debian squeeze ou ultérieur, Apache, php, OpenSSL, Perl,
MySQL, OCS Inventory NG (version 2.0.5), OCS Inventory reports (version
2.0.5)

Clients : Windows Seven, Linux Debian ou autres distributions, OS X.

Ocs inventory-agent (2.0.5)

Jeu d'essai fourni : ocswebInit.sql

Site officiel :
http://www.ocsinventory-ng.org/fr/

Documentation en français :
http://wiki.ocsinventory-ng.org/index.php/Documentation:Main/fr
Mots-clés ITIL, OCS Inventory, Gestion de parcs, Gestion des configurations, inventaire,
télé-déploiement, maintenance, architecture 3-Tier
Durée 8 heures
Auteur(es) Apollonie Raffalli et Cécile Pignon-Nivaggioni notamment pour la partie
spécifique à la spécialité SLAM

Le parc informatique d'une organisation est un assemblage, parfois hétéroclite de matériels

et de logiciels accumulés tout au long des années. On y trouve des :
● matériels différents (téléphones, portables, pc, imprimantes, éléments
d'interconnexions, etc.) qui peuvent être de plusieurs générations ;
● logiciels et systèmes d'exploitations variés (Linux, Windows, Mac OS, etc.) ;
● applications utilisées dans différentes versions ;
● niveaux de sécurité disparates.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 2/29

De plus, la quantité de matériels et de logiciels à gérer, leur éclatement au sein de
l'organisation souvent très étendue dans l'espace, les exigences de performance et de
réactivité font que la gestion de parc est devenue un processus global, complet et
indispensable. Cette activité de gestion de parc informatique est décrite dans le processus
ITIL1 Gestion des configurations.

La gestion du parc informatique recouvre non seulement la fonction d'inventaire de ces

éléments mais aussi celles concernant le suivi et l'évolution :
● Gestion de l'emplacement du matériel
● Gestion des partenaires (fabricants, fournisseurs, transporteurs, prestataires...) et
des contacts associés
● Gestion des contrats (prêt, location, leasing, assurance, maintenance et prestation)
● Gestion des licences logiciels
● Le télé-déploiement de logiciels
● Gestion financière des éléments d'inventaire (matériel loué ou acheté,
amortissement)
● Gestion du cycle de vie de chaque élément
● Gestion des incidents
● Gestion de la documentation informatique (base de connaissance, FAQ, etc.)
● Gestion statistique (nombres d'intervention, coût des consommables, etc.)
● Prévision des besoins (aussi bien matériel, logiciel que de formation en exploitant
notamment les résultats statistiques de la gestion de parc)

Cette gestion de parc permet, d'une part, de répondre aux multiples questions quotidiennes
posées à l'administrateur réseau (quelles sont les versions de Windows installées et sur
quels postes ? Y a-t-il des disques durs proches de la saturation ?, Tel matériel est-il bien
connecté au commutateur ? A quel endroit se trouve tel élément ? Quelle est la valeur
actuelle de tel autre composant ? Quels sont les postes encore sous garantie ?, etc.).

Elle permet, d'autre part, une administration plus globale et à long terme (combien de
machines y aura-t-il à renouveler dans 2 ans ? Quels sont les nouveaux besoins ? Quelles
formations doit-on planifier ? Quel est le retour sur tel investissement ?, Quel est le coût total
de possession – ou TCO – d'un poste ?, etc.).

Le système informatique tisse les liens entre les activités de l'organisation, il importe
donc d'en connaître la composition à tout moment.

L'objectif de ce premier Coté Labo est de simuler, dans la salle laboratoire réseau, la
gestion d'un parc informatique avec la collecte automatisée d'éléments, une gestion
de ces éléments et le déploiement automatisée d'application.
Un deuxième Coté Labo permettra de poursuivre et d'approfondir la gestion des
configurations avec GLPI.

1 ITIL : Information Technology Infrastructure Library - Bibliothèque pour l'infrastructure des

technologies de l'information ; ensemble de documents de référence énonçant les bonnes
pratiques en matière de gestion des services informatiques. www.itilfrance.com
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 3/29
 Contexte logistique et matériel
Vous disposez d'au minimum deux postes. Trois ou quatre postes est préférable. Il est
possible aussi d'utiliser des machines virtuelles :
● un poste pour le serveur qui va accueillir le service de gestion d'inventaire ;
● un ou plusieurs postes clients disposant éventuellement de systèmes d'exploitation
distincts y compris OS X.

Les plate-formes peuvent être situées sur le même réseau ou sur des réseaux distincts.

Nous allons installer l'application OCSInventory-NG (Open Computer and Software

Inventory Next Generation) qui est un outil de collecte automatisée d'éléments d'un parc
informatique puis, dans un premier temps, importer un jeu d'essai composé d'une partie du
parc informatique du lycée dont la topologie logique est la suivante :

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 4/29

Le serveur OCS NG (Open Computer and Software Inventory Next Generation)

Il permet notamment :
● d'automatiser les inventaires des PC connectés sur le réseau ainsi que leurs
composants matériels et logiciels ;
● de connaître l'ensemble des équipements du parc informatique (matériels et
logiciels) avec mise à jour automatique des éléments inventoriés ;
● de procéder à une gestion minimale du parc ;
● de télé-distribuer des fichiers et des applications.

Voici une vue synthétique des principales fonctionnalités d'OCS Inventory :

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 5/29

Architecture d'OCS Inventory

L’application est composée de deux parties :

● Un agent installé sur les machines clientes qui réalise l’inventaire matériel et logiciel ;
● Un serveur (management server) qui centralise les résultats d'inventaire et propose
leur affichage ainsi que la création des paquets de déploiement.

Le serveur de gestion (Management server) comprend quatre composants principaux :

● Le serveur de base de données (Database server), lieu de stockage des
informations d'inventaire.
● Le serveur de communication (Communication server) gère les échanges entre
les agents et le serveur de base de données.
● Le serveur de déploiement (Deployment server) conserve les informations de
configuration des paquets à télé-déployer.
● La console d'administration (Administration console), accessible depuis une
interface WEB très intuitive, permet d'interroger la base de données.

Ces 4 éléments peuvent être installés sur un seul ordinateur ou sur plusieurs afin d'équilibrer
la charge ; le site officiel préconise l'utilisation de deux ordinateurs à partir de 10000
ordinateurs inventoriés.

Les agents doivent être installés sur les machines clientes.

Les communications entre agents et serveurs de gestion utilisent les protocoles

HTTP/HTTPS. Les données sont formatées en XML et compressées avec Zlib pour réduire
l'utilisation de la bande passante du réseau.

Grâce à la fonctionnalité de découverte IP, OCS peut découvrir tous les matériels
connectés au réseau, même ceux pour lesquels aucun agent n'est installé (imprimantes
réseaux, commutateurs, routeurs, etc.). Nous n'utiliserons pas cette fonctionnalité ici car
nous effectuerons cette découverte via un plugin de GLPI offrant plus de fonctionnalités.

Schéma d'articulation des applications (sans le serveur de déploiement) :

Remontée Agent ocs

automatisée

Serveur Serveur de
mysql avec communication
la base "ocs" (ocsinventory-
server) Agent ocs
Remontée semi
automatisée

Console d'administration
(ocsinventory-reports) HTTP
Administrateur avec
navigateur WEB

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 6/29

Déroulement de la séquence

1. Installation et configuration d'OCSinventory (aide en Annexe 1)

● Vérifiez que le serveur de base de données ainsi que le client MySQL sont installés
et opérationnels (obligatoire avant d'installer ocsinventory qui ne détecte pas la
présence ou non de ces paquets).
● Vérifiez que le moteur innoDB soit bien actif dans MySQL. Rappelez un des intérêts
de ce moteur.
● Vérifiez que le serveur web Apache et php sont installés et opérationnels.
● Selon le schéma d'articulation des applications, expliquez quel est le type
d'architecture client/serveur mis en œuvre.
● Installez les services d'OCSinventory nécessaires et procédez à une première
configuration assistée.
● Vérifiez sur le serveur MySQL que la base de données a bien été créée ainsi que
l'utilisateur "ocs". Quels sont les droits donnés à cet utilisateur ?
● Par mesure de sécurité, un certain nombre de modifications sont demandées. Après
en avoir justifié les raisons, procédez à ces modifications.
● Faîtes en sorte que les remontées d'inventaire aient lieu toutes les heures.

Avant d'amorcer l'étape suivante, pour avoir un inventaire de parc

conséquent, vous devez importer en ligne de commande (car le fichier est très
lourd) le jeu d'essai composé d'une partie du parc informatique du lycée.

En cas d’erreur de "duplicata keys" qui survient si vous avez, par mégarde, déjà réalisé
une remontée d’inventaire, il convient de vider les tables suivantes : accountinfo, bios,
controllers, drives, hardware, inputs, memories, modems, monitors, netmap, networks,
ports, printers, slots, softwares, softwares_name_cache, sounds, storages, videos.

2. Installation et configuration de l'agent (aide en Annexe 2)

● Installez dans un premier temps l'agent sur le serveur ocsinventory-agent pour la
collecte d'information propre au serveur lui-même.
● Forcez le premier inventaire (n'hésitez pas à consulter les log en cas de problèmes)
● Installez ensuite les agents sur chacun de vos postes clients sous Windows, sur
Linux et sur Mac OS X en forçant le premier inventaire. Pour chaque poste sous
Windows, précisez :
➔ quelle est la valeur de votre variable TTO_WAIT à l'installation et donc dans
combien de temps aura lieu le second inventaire ?
➔ quelle est la valeur de la variable PROLOG_FREQ ?
Redémarrez le service OcsInventory de manière à ce que la variable s'ajuste en
fonction de PROLOG_FREQ et précisez la nouvelle valeur de la variable
TTO_WAIT.
● Proposez une ou plusieurs solutions d'automatisation du déploiement de l'agent
depuis le serveur.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 7/29

3. Exploitation d'OCSInventory (aide en Annexe 3)

● L'administrateur réseau se pose quelques questions précises et vous demande d'y

répondre en remplissant la première partie du tableau qu'il a préparé en Annexe A.
● Remontez de la base de registre au moins une clé d'un des applicatifs installés sur
un poste Windows, la clé indiquant l'ensemble des processus lancés
automatiquement au démarrage de la machine :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run et
les clés de licence de chaque application installée. Quel peut être l'intérêt de
connaître ces informations ?
● Ajoutez trois informations administratives : date d'achat, date de fin de garantie et la
fonction de la machine (client ou serveur).

Avant le point suivant qui consiste à exécuter un script qui va impacter l’ensemble
des enregistrements, procédez à une sauvegarde (en ligne de commande via
l’utilitaire mysqldump) de votre base de données.

● Dans un environnement professionnel, il est primordial de connaître la localisation du

matériel ; Le champ "tag" peut être utilisé pour référencer les salles. Lorsqu'il sera
prêt (et testé), exécutez le script réalisé au point 4.
● Complétez la deuxième partie du tableau de l'Annexe A.
● L'administrateur pense qu'il est possible de déléguer certaines fonctionnalités de la
gestion du parc selon les salles du lycée. Testez et écrivez la procédure.

4. Mise à jour de la localisation des STA et des serveurs inventoriés – Spécialité SLAM

Pour obtenir un inventaire cohérent et efficace, il est nécessaire de modifier le TAG de

chaque machine inventoriée afin d'y indiquer sa localisation (par exemple 202 pour la salle
202). Effectuer cette manipulation manuellement est ingérable selon l'ampleur du-dit parc.
L'objectif de cette partie est d'obtenir un script permettant une automatisation de la mise à
jour de la localisation des STA et des serveurs inventoriées.

Depuis cette année, une nouvelle nomenclature pour les postes est utilisée :
numéro-de-la-salle_numéro-du-poste

Par exemple le premier poste de la salle 231 aura pour nom : 231_01.
Il existe également des salles dont le nom n'est pas un numéro comme par exemple « cdi »,
« svt » ou « sdp » (salle des professeurs).

Pour les serveurs, le nom est construit de la façon suivante :

« serv » suivi du rôle du serveur
Par exemple, le serveur sur lequel sont installés les outils de gestion de parc sera nommé :
servGestParc

● Écrivez la requête SQL permettant de mettre à jour automatiquement les TAG des
postes de la salle 204.
● Sachant que les 3 premiers caractères du nom de chaque poste correspondent à la
salle dans laquelle il est situé, proposez un script bash « majTAG.sh » qui permet de
créer un fichier « salles.txt » contenant la liste des salles du lycée.
● Sachant que tous les serveurs sont situés dans le Local Technique (salle « LT »),
proposez une solution (sans la coder) pour mettre à jour leur TAG.
● Complétez ce script pour permettre l'automatisation de la mise à jour des TAG de
tous les postes et les serveurs inventoriés.

Ce script devra être transmis aux SISR afin que la localisation des STA soit
également configurée sur leur inventaire.
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 8/29
 ● Modifiez le script pour que, lors de son exécution, l'identifiant et le mot de passe de
l'utilisateur ayant les droits sur la base de données « ocsweb » soient demandés
sans que ces derniers apparaissent à l'écran.
● Préparez une archive contenant le script « majTAG.sh » accompagnée d'un
document expliquant son rôle et son utilisation.

5. Intégration de modules complémentaires – Spécialité SLAM

La version 2.0 de l'interface web OCS a complètement été repensée pour permettre à
chacun d'apporter son développement par système de module.
Ainsi, le cœur de l'interface web d'OCS est dissocié des modules complémentaires (ou
plugins).
Quelques plugins sont disponibles sur le WIKI officiel à l'adresse http://wiki.ocsinventory-
ng.org/index.php/Plugins:version2/fr.
Il est également possible de développer son propre plugin et ainsi de personnaliser
l'interface web ou d'ajouter des fonctionnalités.
(documentation :http://wiki.ocsinventory-ng.org/index.php/Documentation:Plugins/fr )

Sous linux, les plugins sont installés dans le répertoire /usr/share/ocsinventory-

reports/plugins.

● Intégrez le plugin « Top 10 des logiciels / Agents Ocs / Systèmes d'exploitation

installés ».

Ce plugin présente des erreurs à l'installation qu'il est nécessaire de corriger.

● Préparez une archive avec le plugin corrigé afin que les SISR puissent l’installer.

6. Déploiement d'un fichier ou d'une application (aide en Annexes 4 et 5) – Spécialité

SISR

● Créez un certificat pour le serveur OCS, configurez Apache 2 et chaque client OCS
(Annexe 5) ; vous testerez en ligne de commande l'écoute sur le port 443.
● Après avoir testé le déploiement de l'utilitaire putty (Annexe 4), procédez à un
déploiement d'une application de votre choix ; vous trouverez sur le site
http://www.appdeploy.com/packages/ toutes les commandes nécessaires pour une
installation silencieuse.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 9/29

Annexes

Annexe 1 : installation et configuration du service OCSInventory

OCSInventory travaille dans un environnement web qui fait appel à des scripts php, perl et au SGBD
MySQL pour le stockage des informations d'inventaire ; Il est donc nécessaire de disposer d'un
serveur Apache2 et du SGBD MySQL (peu importe la version) avec le moteur innoDB opérationnels.
Attention, l'installation du serveur et du client MySQL est obligatoire avant (ou pendant)
l'installation d'ocsinventory car aucune dépendance n'a été prévue !

La version d'OCSInventory dont il est question ici est 2.0.5-1.

C'est la version qui s'installe automatiquement si vous êtes sur une Debian "Wheezy" (debian stable
actuelle).

Les paquets à installer sont les suivants :

● ocsinventory-reports - Hardware and software inventory tool (Administration Console)
● ocsinventory-server - Hardware and software inventory tool (Communication Server)

Et éventuellement ocsinventory-agent pour que le serveur ocsinventory soit répertorié dans la base.

Selon ce que vous avez déjà sur votre système, d'autres paquetages seront nécessairement installés,
voir mis à jour.
Tout ce qui suit est basé sur la version 2.0.5-1 du serveur ; si vous installez une version ultérieure,
les répertoires et noms de fichier seront peut-être différents ; il faudra dans ce cas adapter certaines
commandes.

À priori, le système debconf de debian ne propose plus une aide à la configuration des éléments
indispensables à la partie serveur d'OCS (comme dans la version précédente).
Il est donc nécessaire de finaliser l'installation via l'interface Web : http://@IPserveur/ocsreports/

Il faut saisir ici le mot

de passe de
l'utilisateur "root" qui
a le privilège de
pouvoir créer une
base de données
dans mysql

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 10/29

Cliquez sur send et vous devez voir apparaître l'écran suivant (ne pas faire attention aux warning) :

Cliquez sur le lien pour accéder à l'interface d'administration

Les fichiers de configuration de chacune des applications se trouvent dans /etc/ocsinventory
Un répertoire "ocsinventory-server" est créé dans /usr/share/
Un répertoire "ocsinventory-reports" est créé dans /usr/share/ et dans /var/lib/
La documentation de chacune des applications se trouve dans /usr/share/doc/

Les logs iront dans le répertoire : /var/log/ocsinventory-server/ mais il faut au préalable les
activer en positionnant à "on" la variable "LOGLEVEL" (voir en fin d'annexe).

La configuration pour le serveur WEB : /etc/apache2/conf.d/ocsinventory.conf et

/etc/apache2/conf.d/ocsreports.conf

La base de données "ocsweb" avec 94 tables sera créée.

Un utilisateur mysql « ocs » qui a un certain nombre de droits sur cette base de données est créé
par défaut avec comme mot de passe « ocs » ; les fichiers :
• /usr/share/ocsinventory-reports/dbconfig.inc.php
• /etc/apache2/conf.d/ocsinventory.conf
accueillent les variables de configuration) ==> Il est donc nécessaire de modifier ces deux fichiers si
on modifie (comme il est évidemment conseillé de le faire) le mot de passe.

Ne pas oublier de redémarrer Apache2 après la modification de ces fichiers sinon vous
risquez d'avoir une erreur 500 correspondante à une « Internal error ».

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 11/29

La console d'administration

La gestion du parc se réalise via la console web d'administration. On accède à cette console
avec l'URL suivante : http://@IPserveur/ocsreports/ :

Un compte par défaut "admin" Choisir

avec le mot de passe "admin" a français
été créé (table operators). Ces
variables peuvent être modifiées
via l'interface.

Par sécurité, il faut :

- supprimer ou renommer le fichier « install.php » qui est à la racine du
serveur Web d'ocsreports
- modifier le mot de passe d'admin
- modifier le mot de passe de l'utilisateur mysql « ocs » et changer en
conséquence dans les fichiers « dbconfig.inc.php » et « ocsinventory.conf » Changer le mot de
d'Apache2 passe de admin

La page d'accueil de l'administration est la suivante :

Gestion des
utilisateurs

Un "clic" sur chaque onglet et sur chaque icône devrait déjà vous donner un aperçu des
fonctionnalités.

Le module "configuration" va permettre, entre autres, de gérer le rythme des remontées d'inventaire.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 12/29

Le but étant de ne pas trop charger le réseau, il faut éviter :
● de faire des remontées constamment ;
● de faire des remontées systématiques lors de chaque lancement du client ;
● de faire les remontées de tous les clients en même temps.

Ce sont les paramètres PROLOG_FREQ (onglet serveur) et FREQUENCY (onglet Inventaire) qui
gèrent le rythme des inventaires.

Il vaut mieux mettre

la variable à "ON"

PROLOG_FREQ définit en nombre d’heure la période max entre 2 lancements d'un agent. Cette
notion de “période max” permet d'éviter les surcharges si tous les postes remontaient leur inventaire
simultanément ; l’agent choisit un temps de manière aléatoire pouvant aller jusqu'à cette période max
pour demander au serveur quoi faire – pas nécessairement remonter l’inventaire.

C'est la valeur de la variable FREQUENCY qui va réellement permettre le lancement de l'inventaire :

● Toujours inventorié (always) : la remontée sera réalisée sans condition dès que l'agent
sollicite le serveur (c'est la valeur par défaut)
● Jamais inventorié (never) : aucune remontée ne sera réalisée.
● Personnalisé (custom) : définit une fréquence de remontée d'inventaire en nombre de
jours : la remontée sera réalisée lors de la sollicitation du client si l'inventaire est plus vieux
que le nombre de jours spécifiés dans FREQUENCY.

Exemples :
FREQUENCY = toujours inventorié et PROLOG_FREQ = 24 : toutes les 24 heures au max, je
force une remontée qui sera faite à chaque fois
FREQUENCY = 1 et PROLOG_FREQ= 12 : toutes les 12 heures au max, l'agent demande au
serveur s'il n'est pas temps de réaliser un inventaire. Celui-ci acceptera si l’inventaire actuel a plus
d'un jour.

Pour approfondir les différentes possibilités de configuration :

http://wiki.ocsinventory-ng.org/index.php/Documentation:Administration/fr

Désactivez IpDiscover !
La fonctionnalité de découverte automatique "IpDiscover" ne sera pas mise en œuvre et en
fonction de l’étendu du réseau, les remontées d’inventaire peuvent être fortement ralenties
si celle-ci est activée.

Il faut pour cela, positionner la valeur "IPDISCOVER" à "OFF" :

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 13/29

Annexe 2 : La collecte d'informations

La collecte automatisée d'informations passe par l'installation sur les postes clients de l'agent ocs ; Il
existe un (ou plusieurs) agent(s) pour chaque système d'exploitation.
Nous ne développerons pas la problématique de l'installation automatique de l'agent mais il est évident
qu'en production lorsque l'agent doit être installé sur des centaines de postes, la question se pose (voir
compléments proposés).

Installation de l'agent sous Linux Debian

#apt-get install ocsinventory-agent

Le système propose une configuration d'ocsinventory-agent. Choisir la méthode "HTTP" qui permet
de remonter les informations à un serveur OCS, puis saisir lorsque cela est demandé le nom d'hôte du
serveur :

La méthode locale permet la récupération des informations dans un fichier XML (intéressant si le poste
ne peut pas se connecter au réseau) puis l'incorporation manuelle dans OCS. "HTTP" est, ici, la
méthode qui convient puisque tous les postes peuvent accéder au serveur OCS via le réseau.

Il suffit ensuite de saisir le nom d'hôte du serveur d'inventaire ou son adresse IP.

Un répertoire /var/log/ocsinventory-client destiné à accueillir le fichier de log est également créé.

3 fichiers sont créés :

● Un fichier de configuration "/etc/ocsinventory/ocsinventory-agent.cfg" dans lequel vous
trouverez notamment le nom d'hôte (ou l'adresse IP) précisé précédemment.
Exemple de fichier ocsinventory-agent.cfg :
server=serveurDebian
tag=Linux_Serveur

Le "TAG" représente une rapide description de la machine (et permettra des recherches par
catégorie) : s'il n'a pas été précisé lors de la configuration de l'agent, il peut être ajouté ou modifié via
la console d'administration du serveur.
● Le fichier de rotation des logs : /etc/logrotate.d/ocsinventory-agent qui configure la rotation
quotidienne des logs de l'agent OCS Inventory NG
● Un script pour l'agent (une tâche cron) : /etc/cron.daily/ocsinventory-agent ; ce script
s'exécutera chaque jour à l'heure précisée dans /etc/crontab (0 heures 26 dans l'exemple ci-
dessous) :
26 0 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

La première remontée d'inventaire ne se fera qu'à l'heure indiquée et ensuite le rythme des remontées
dépendra des valeurs des variables PROLOG_FREQ et FREQUENCY définies dans l'annexe 1.

Pour forcer la remontée d'inventaire une première fois sans attendre le premier déclenchement
du cron, il suffit d'exécuter la commande ocsinventory-agent.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 14/29

En cas de problème (l'inventaire n'apparaît pas par exemple) ou si vous voulez en savoir plus sur la
communication entre l'agent et le serveur, la documentation propose la commande suivante :
ocsinventory-agent -debug
Théoriquement, cela a pour objectif de forcer l'agent à produire plus de détails dans le fichier log,
montrant les échanges XML avec le serveur de communication mais j'ai pour ma part une sortie écran
(canal standard) et aucun fichier log créé ou lorsqu'il est créé qui se "remplit".

En attendant mieux, une solution pour conserver la sortie du debug dans un fichier :
ocsinventory-agent --debug &> /var/log/ocsinventory-client/ocsinventory-
agent.log

Dès lors qu'un premier contact a été établi, des fichiers XML sont créés sur le poste dont :
/var/lib/ocsinventory-agent/http:__serveurDebian_ocsinventory/last_state
/var/lib/ocsinventory-agent/http:__serveurDebian_ocsinventory/ocsinv.adm
/var/lib/ocsinventory-agent/http:__serveurDebian_ocsinventory/ocsinv.conf

last_state décrit le dernier inventaire réalisé.

Dans ocsinv.conf, on trouvera les paramètres de configuration générale comme la valeur de la
variable PROLOG_FREQ (ce qui veut dire que si cette variable est modifiée sur le serveur OCS, elle
ne sera prise en compte par le client qu'après le prochain inventaire). Il est toujours possible de la
modifier directement dans le fichier.
ocsinv.adm enregistre les valeurs TAG et autres valeurs administratives

Exemple ocsinv.conf :
<CONF>
<DEVICEID>squeezeApoR1-2012-10-08-16-22-21</DEVICEID>
<PROLOG_FREQ>1</PROLOG_FREQ>
</CONF>

Exemple ocsinv.adm :
<ADM>
<ACCOUNTINFO>
<KEYNAME>TAG</KEYNAME>
<KEYVALUE>Linux_Serveur</KEYVALUE>
</ACCOUNTINFO>
</ADM>

Cliquez ici, dans la console d'administration, pour voir l'ensemble des machines inventoriées

Un clic sur le nom d'une machine permet d'afficher, dans un autre onglet, les détails inventoriés du
poste.

Remarque : au niveau du client Linux intégré par défaut sous Debian, il n'y a pas en fait de gestion du
PROLOG_FREQ ce qui fait que la fréquence d'inventaire est la fréquence quotidienne défini par le
"cron" du départ.

Installation de l'agent sous Windows

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 15/29
Sous Windows, deux agents OCSinventory sont disponibles :
● OcsLogon.exe : cet agent peut être utilisé uniquement sur un domaine Active Directory ou
sur Linux via Samba. Il peut être déployé à travers le contrôleur de domaine et par des scripts
d'ouverture de session.
● OCS-NG-Windows-Agent-Setup.exe : cet agent s'installe sur chaque poste et permet la
transmission d'inventaire et également le déploiement d'applications à distance. Une fois
installé, le service OCSinventory se lance à chaque démarrage du poste.
Dans le cadre de notre TP, c'est celui que nous utiliserons.

NB : il est aussi possible de créer un fichier ocspackage.exe en utilisant le packager OCS Inventory
NG, pour déployer la version de l'agent de service Windows, même si l'utilisateur connecté n'a pas les
droits d'administrateur.

Il est nécessaire de récupérer sur le site d'OCS (http://www.ocsinventory-ng.org/fr/) l'archive qui

contient les 2 agents sus-mentionnés : au jour où ces lignes sont écrites, le fichier est : OCSNG-
Windows-Agent-2.0.5.zip. Attention, la version de l'agent doit être inférieure ou égale à celle du
serveur.

Il suffit ensuite d'extraire l'archive et d'exécuter OCS-NG-Windows-Agent-Setup.exe. Un fichier de log

(OcsAgentSetup) rendant compte de l'installation (à consulter en cas de problème ou par curiosité) est
créé dans le répertoire où se trouve l'exécutable OcsAgentSetup.exe que l'on vient de lancer.

Pour avoir le détail de l'installation (et maîtriser toutes les options) : http://wiki.ocsinventory-
ng.org/index.php/Documentation:WindowsAgent/fr

Après validation de la licence, vous arriverez à l'écran suivant :

Server URL : adresse IP du serveur de Communication OCS Inventory (/SERVER:10.22.100.100)

La « notion » de certificat sera utile lors du déploiement ou lorsqu'on basculera en HTTPS pour
avoir une remontée d'inventaire sécurisée : on y reviendra.

Après « Suivant », saisir le paramétrage du proxy si nécessaire puis cliquez sur « Suivant ».

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 16/29

 Nous gérerons les
TAG globalement
par la suite.

Enable log file : un fichier de log au nom de la machine est créé dans le répertoire d'installation à
chaque remontée d'inventaire (/DEBUG)
Immediatly lauch inventory (/NOW) : lance une première fois OCS inventory (le premier inventaire
est réalisé)

Choisissez ensuite un répertoire de destination, C:\Program Files\OCS Inventory Agent par défaut et
cliquez sur le bouton Installer.

La dernière fenêtre est la suivante :

Installe une « applet » dans

la barre des tâches
permettant notamment de
lancer l'inventaire
manuellement

Les répertoires d'installation sont, par défaut

• C:\Program Files\OCS Inventory Agent\ pour les exécutables et dll
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 17/29
 • C:\ProgramData\OCS Inventory NG\Agent\ pour les fichiers de configurations et les fichiers
d'activité (log)

Une fois l'agent installé sur le client, le service OCSinventory est configuré pour être lancé
automatiquement en tant que service au démarrage.

Les paramètres de configuration se trouvent dans le fichier C:\ProgramData\OCS Inventory

NG\Agent\ ocsinventory.ini.

[OCS Inventory Agent]

ComProvider=ComHTTP.dll
...
NoTAG=0
IpDisc=
[HTTP]
Server=http://10.22.100.100/ocsinventory
SSL=1
CaBundle=cacert.pem
...
[OCS Inventory Service]
PROLOG_FREQ=1 Valeur synchronisée à chaque connexion au serveur
OLD_PROLOG_FREQ=24 Valeur par défaut puis ensuite même valeur que PROLOG_FREQ
TTO_WAIT=78900

La variable TTO_WAIT représente en secondes le nombre d'heures d'attente ; elle est décrémentée
de "1" à chaque seconde par le service (le fichier service.ini est ré-écrit toutes les minutes). Lorsqu'elle
arrive à "0", l'agent exécute la commande OCSinventory.exe suivi des options contenues dans le
fichier de configuration (il est possible de « surchager » la valeur des options en passant des
arguments à la commande OCSinventory.exe).
La commande va transmettre la remontée d'inventaire au serveur si l'inventaire est plus vieux que le
nombre de jours spécifiés dans la variable FREQUENCY.

Exemples :
FREQUENCY = toujours inventorié et PROLOG_FREQ = 24 : toutes les 24 heures au max, je force
une remontée qui sera faite à chaque fois
FREQUENCY = 1 et PROLOG_FREQ= 12 : toutes les 12 heures au max, l'agent demande au serveur
s'il n'est pas temps de réaliser un inventaire. Celui-ci acceptera si l’inventaire actuel a plus d'un jour.

Une fois que le service a lancé l'agent, il recalcule de manière aléatoire le TTO_WAIT compris entre 1
et la valeur de PROLOG_FREQ (convertie en secondes) synchronisée avec la variable
correspondante sur le serveur OCSinventory.

À l'installation de l'agent, le contenu de la variable TTO_WAIT est défini aléatoirement et

inférieur à 86 400 secondes (correspondant à 24h qui est le contenu par défaut de la variable
PROLOG_FREQ).

Pour forcer l'inventaire d'une machine immédiatement, il suffit d'exécuter la commande

OCSinventory.exe ou de lancer la commande via l'applet de la barre des tâche (si on l'a installée).

Pour forcer l'inventaire d'une machine dans un temps défini :

● Arrêt du service OCS INVENTORY SERVICE
● Édition du fichier C:\ProgramData\OCS Inventory NG\Agent\ocsinventory.ini.
● Affectation d'une faible valeur à TTO_WAIT (30 par exemple).
● Redémarrage du service OCS INVENTORY SERVICE
Ainsi, après 30 secondes le client doit être mis à jour dans l'inventaire.

Chaque remontée d'inventaire entraîne l'inscription et le déroulement de la remontée dans le fichier

d'activités « ocsinventory.log » (attention : sous windows, afficher les extensions pour ne pas
confondre avec le fichier « ocsinventory.log.bak »).

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 18/29

Annexe 3 : gestion des informations collectées
Une fois les inventaires transmis au serveur par les agents et intégrés à la base de données,
l'ensemble des machines peut être visionné.
Des requêtes de restrictions pourront également être effectuées permettant ainsi d'avoir une vue
précise et ciblée des éléments informatiques présents dans l'entreprise.

Les outils principaux de visualisation et de gestion

des résultats de l'inventaire

Onglets qui
permettent d'obtenir
un certain nombre
d'informations sur
l'ensemble du parc

Il suffit de passer la souris sur les icônes de la barre d'outil pour avoir une explication générale.

Les différents menus sont très intuitifs, il est inutile de les détailler ; vous pouvez consulter la
documentation ici : http://wiki.ocsinventory-ng.org/index.php/Documentation:Results/fr
ou pour une version plus à jour (mais en anglais) :
http://wiki.ocsinventory-ng.org/index.php/Documentation:Results
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 19/29
À noter qu'il est notamment possible de (liste non exhaustive) :

● personnaliser la vue en ajoutant ou supprimant des colonnes, en changeant le nombre de

lignes par page à afficher ;
● rechercher selon de multiples critères
● créer des groupes statiques ou dynamiques de machines, le groupe dynamique se
mettant à jour automatiquement ; aussi il n'est possible de créer un groupe dynamique
que sur la base d'une recherche par critère(s) et toutes les machines trouvées actuelles et
futures intègrent automatiquement le groupe. L'intérêt est multiple :
– cela permet d'avoir une vue permanente des machines répondant à un ou plusieurs
critères sans avoir à chaque fois à refaire la même recherche (par exemple pour
repérer les machines ayant Microsoft Office alors qu'il n'existe pas de licence,
rassembler les machines qui vont faire l'objet d'un déploiement, etc) ;
– cela permet d'appliquer une configuration différente à un groupe de machine (par
exemple une valeur de PROLOG_FREQ plus forte ou plus faible) ;
Vous trouverez la documentation ici :
http://wiki.ocsinventory-ng.org/index.php/Documentation:Groups/fr
● visualiser et "catégoriser" les logiciels présents sur les machines : icônes
cette dernière icône (Dictionnaire) servant notamment pour la gestion des
logiciels avec GLPI
● visualiser et gérer les doublons
● ajouter des informations administratives (date de fin de garantie, etc)
● réaliser des requêtes sur le registre ;

Récupération des clés de registre

Une des fonctionnalités intéressantes de la gestion d'un parc est de permettre la gestion des
licences logicielles ; pour cela certaines clés de registres (sur les systèmes Windows uniquement)
doivent être récupérées.
Par défaut, aucune clef de registre est récupérée par les agents OCSinventory. C'est donc à
l'administrateur du service d'inventaire de définir celles qui doivent l'être. Pour ce faire :
● Activer l'option dans la configuration générale (menu configuration, onglet registre, mettre le
paramètre à "on").
● Définir les clés avec le menu "registre"u udans la barre d'outils en cliquant sur le bouton
"Ajouter" :
Soit la clé pour récupérer la licence d'office 2007 sous XP :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration\{90120000-0051-0000-
0000-0000000FF1CE}

Après validation :

Vous pouvez ensuite visualiser le résultat, après la prochaine remontée d'inventaire (que l'on peut
provoquer manuellement) ; lors de la vue de chaque poste via l'icône :

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 20/29

Annexe 4 : le déploiement d'une application
L'installation, la mise à jour et la suppression d'applications font partie du travail quotidien d'un
administrateur réseau. Lorsque le parc de machine s'agrandit, il devient très intéressant d'automatiser
cette tâche.

Préalables :
● Sur le serveur OCS, le déploiement d'application n'est pas activé par défaut ; il faut mettre le
paramètre DOWNLOAD à "on" (menu "Configuration", onglet "Teledeploiement") ; mettre
aussi 15 secondes à DOWNLOAD_PERIOD_LATENCY (temps d'attente entre 2 périodes de
télé-déploiement).
● Il faut aussi modifier le chemin du répertoire "download" qui est le répertoire par défaut où les
agents vont télécharger le paquet ou les fragments de paquet ainsi qu'un fichier XML
d'information : dans les variables DOWNLOAD_URI_FRAG et DOWNLOAD_URI_INFO,
changer localhost par l'adresse IP du serveur.
● Le déploiement d'applications ne fonctionne qu'avec un serveur WEB sécurisé utilisant le
protocole HTTPS basé sur l'authentification SSL, il est donc nécessaire de configurer le
serveur HTTPS basé sur l'authentification SSL (Annexe 5).

1. Préparation d'une archive

Schéma de fonctionnement général : compressé (zip ou tar.gz)
Avec la console d'administration :
2. Création du paquet
3. Activation du paquet
4. Affectation du paquet
7 1
2, 3, 4
6
5 Administrateur
8 5. L'agent se connecte pour demander ce qu'il doit faire
6. Le serveur de communication lui donne l'ordre de déployer
9 7. L'agent se connecte au serveur HTTPS pour récupérer un
fichier d'informations
8. L'agent se connecte éventuellement à un serveur HTTP pour
télécharger des fichiers
9. L'agent exécute et renvoie un code résultat
Le principe de base est le suivant :
● Comme nous l'avons déjà vu, l'agent se connecte au serveur de communication par le
protocole HTTP pour lui demander ce qu'il doit faire. En fonction de sa configuration, le
serveur peut répondre :
– d'envoyer un inventaire ;
– de découvrir le réseau avec le service IpDiscovery ;
– de déployer un ou plusieurs paquets ;
– de ne rien faire.
● Lorsque l'agent a l'ordre de déployer un paquet, il contacte via le protocole HTTPS le
serveur de déploiement afin d'y récupérer un fichier d'informations (IDA : "Instruction
Déploiement d'Applications") associé qui est un fichier XML décrivant le paquet et l'action
que l'agent devra exécuter. C'est un fichier qui dispose d'un champ d'action important d'où
la nécessité de sécuriser et d'authentifier le serveur sur lequel il se trouve.
L'agent devra éventuellement télécharger, via le protocole HTTP, un fichier ou des
fragments de fichiers (ce dernier point est optionnel si les instructions ne consistent qu'à
exécuter une ou plusieurs commandes).

L'administrateur devra au préalable :

● préparer une archive compressée (en .ZIP pour Windows et en .tar.gz pour Linux) des fichiers
nécessaires
● créer le paquet grâce à la console d'administration.
● activer le paquet
● affecter le paquet aux machines sur lesquelles le déploiement doit s'effectuer

Nous partirons d'un exemple simple : nous déploierons sur les postes windows l'utilitaire "putty" (qui ne
consiste qu'en un fichier "putty.exe") dans le répertoire "Program files".
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 21/29
L'outil de déploiement de la barre d'outil est dont nous allons utiliser les sous-menu
"Création" et "Activation".

Création du paquet à déployer

Le nom du paquet à déployer auquel sera associé un identifiant unique dans la base de données.
Le système : Il est possible de déployer des paquets sur Windows ou sur Linux.
Le protocole utilisé pour le transfert des données est HTTP.
La priorité permet de définir quels paquets doivent être installés avant d'autres. Au total 11 niveaux de
priorité sont disponibles. Plus le chiffre défini comme priorité est bas, plus la priorité sera forte.
La priorité 0 est donc la plus forte, mais attention, celle-ci doit être utilisée avec précaution car un
paquet ayant cette priorité devra obligatoirement se déployer correctement sinon l'ensemble des
autres paquets ne seront pas déployés. La priorité 5 (proposée par défaut) convient la plupart du
temps.
Le fichier : selon la documentation, tous les paquets doivent être compressés en ZIP pour l'agent
Windows et en TAR.GZ pour les ordinateurs Linux. Cette archive compressée doit donc être
préparée préalablement.

Trois types d'actions sont disponibles:

● Lancer : pour déployer un fichier ZIP ou TAR.GZ et lancer avec ou sans paramètre un fichier
exécutable incluant un fichier ZIP ou TAR.GZ.
Le fichier ZIP ou TAR.GZ sera décompressé dans un répertoire temporaire, et la commande
associée (le nom du fichier exécutable sans le chemin !) sera lancée dans le répertoire
temporaire.
● Exécuter : pour déployer un fichier ZIP ou TAR.GZ (optionnellement), et lancer avec ou sans
paramètre un fichier exécutable incluant ou non un fichier ZIP ou TAR.GZ.
Si l'exécutable n'est pas inclus dans le fichier ZIP ou TAR.GZ, il doit être une partie de logiciel
toujours installé dans l'ordinateur client. Typiquement, cela peut être une commande Windows
standard tel qu'un appel de l'installeur Windows, commande RPM, DPKG ou TAR.GZ sur
Linux.
Le fichier ZIP ou TAR.GZ sera décompressé dans un répertoire temporaire, et la commande
associée (le nom du fichier exécutable avec le chemin ou les paramètres si besoin) sera
lancée dans le répertoire temporaire.
http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 22/29
 ● Stocker : pour déployer un fichier ZIP ou TAR.GZ et enregistrer seulement son contenu dans
un enregistrement de son ordinateur client. Il faut donc donner le chemin de stockage sur
l'ordinateur client.

Après un clic sur le bouton de commande "Envoyer", la fenêtre qui doit s'afficher est la suivante :

Fragmenter un paquet permet de :

● télécharger chaque fragment individuellement et autoriser la reprise sur incident lors d'un gros
paquet à télécharger (seul le fragment perdu sera téléchargé à nouveau)
● ne pas saturer le réseau
Mais en contrepartie, s'il y a beaucoup de fragments, le téléchargement peut être long selon les
réglages (priorité et paramètres du serveur).
En effet, Le télé-déploiement se déroule par période composée de cycles (variable
DOWNLOAD_PERIOD_LENGTH à 10 par défaut). A chaque début de cycle, un calcul va être effectué
: "numero de cycle" modulo "priorité du paquet" . Si le résultat de ce calcul est égal à 0, alors un
fragment du paquet sera téléchargé (donc tous les 5 cycles pour une priorité égale à 5). Une fois le
téléchargement de ce fragment terminé, il va y avoir une pause correspondant à
DOWNLOAD_FRAG_LATENCY. A chaque fin de cycle, il va aussi y avoir une pause correspondant à
DOWNLOAD_CYCLE_LATENCY. Une fois que tous les cycles d'une période se seront déroulés, il y
aura encore une pause correspondant à DOWNLOAD_PERIOD_LATENCY avant de passer à la
période suivante. Et ainsi de suite... Lorsque tous les fragments seront téléchargés, ils seront
rassemblés en un seul fichier qui sera lancé, exécuté ou stocké.
En conclusion, sur un réseau local et si le paquet n'est pas très gros, un seul fragment est préférable à
plusieurs.

Et on peut aussi constater que le fichier XML "info" a aussi été créé automatiquement dans ce
répertoire :
#root@squeezeApoR1:~#ls -l /var/lib/ocsinventory-reports/download/1350234404/
total 268
-rw-r--r-- 1 www-data www-data 264347 Oct 14 17:12 1350234404-1
-rw-r--r-- 1 www-data www-data 372 Oct 14 17:12 info

Un seul fragment
Activation du paquet

Une fois construits les paquets doivent être activés.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 23/29

Serveur HTTPS : c'est le serveur où doit être téléchargé le fichier d'instructions XML (info)
Serveur HTTP : c'est le serveur où sera(ont) téléchargé(s) le (ou les) fragment(s)
Ce sont les URLs passées en argument à l'agent.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 24/29

Affectation d'un paquet

Une fois le paquet activé, il est possible de le déployer facilement sur un nombre important de postes.
Le plus simple est d'effectuer une recherche (dans notre exemple les ordinateurs qui exécutent un
système d'exploitation Windows) ou utiliser un groupe dynamique ou statique puis de cliquer sur le lien
l'icône "Teledeployer".

Cliquez sur "Select" et les postes clients seront avertis (notifiés) qu'un paquet doit être déployé dès
leur prochaine communication avec le serveur (que l'on peut/doit provoquer...).
Ils téléchargeront alors dans un premier temps le fichier d'instructions XML et ensuite, s'il y a lieu, les
différents fragments du paquet.

Le résultat est progressivement visible à partir du sous-menu "Activation" :

2 postes (sur les 3) n'ont pas encore été Un paquet a été déployé
notifiés avec succès

Des diagrammes sont disponibles pour chaque déploiement de paquet.

Ils permettent de disposer d'une image précise du déploiement et de voir quels sont les
postes qui ont été notifiés ou pas, ceux dont le déploiement a réussi, ceux qui sont en
échec, etc...

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 25/29

Sur le client, les logs vous renseignent sur un éventuel problème :

OCSInventory.log. Si tout va bien, vous devriez avoir ces lignes adaptées à votre contexte (à la fin du
fichier) :
INVENTORY => Writing new inventory state
AGENT => Communication Server ask for Package Download
DOWNLOAD => Package history file successfully cleaned for duplicate
IDs
DOWNLOAD => Metadata file <info> for package <1350234404> is located
at <https://10.22.100.100/download/1350234404/info>
COM SERVER => Initializing cURL library for getFile
COM SERVER => Using cURL without server authentication
COM SERVER => Disabling cURL proxy support
COM SERVER => Enabling cURL SSL server validation support using CA Bundle
<cacert.pem>
COM SERVER => Sending fileGet request to URL
<https://10.22.100.100/download/1350234404/info>
COM SERVER => fileGet response received <HTTP Status Code #200>
COM SERVER => Cleaning cURL library
DOWNLOAD => Unloading communication provider
DOWNLOAD => Retrieve info file...OK (pack 1350234404)
DOWNLOAD => Package <1350234404> added to download queue
DOWNLOAD => Download and setup tool successfully started
AGENT => Unloading communication provider
AGENT => Unloading plug-in(s)
AGENT => Execution duration: 00:00:12.

Download.log. Si tout va bien, ce fichier doit se terminer par :

C:\Program Files\OCS Inventory Agent\download - Message [SUCCESS]
successfully sent
C:\Program Files\OCS Inventory Agent\download - Cleaning package
1267218957
C:\Program Files\OCS Inventory Agent\download - Now pausing for
fragment latency
C:\Program Files\OCS Inventory Agent\download - Now pausing for cycle
latency(60 secs)
C:\Program Files\OCS Inventory Agent\download - Now pausing for
period latency(15 secs)
C:\Program Files\OCS Inventory Agent\download -
Everything done...
C:\Program Files\OCS Inventory Agent\download - End of work

En observant ce dernier fichier, vous pouvez constater toutes les pauses effectuées (et le temps mis
pour le déploiement).

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 26/29

Annexe 5 : configuration d'un serveur HTTPS
Le serveur HTTPS sera sur le même serveur physique que le serveur OCS.
Cette annexe ne constitue en aucun cas un TP/cours sur les protocoles HTTPS et SSL. Voir pour plus
de plus de précision le Coté labo « le service Web sécurisé » :
http://www.reseaucerta.org/content/service-web-s%C3%A9curis%C3%A9

Les clé privée, publique et le certificat vont être créés avec l'utilitaire "OpenSSL" ; en conséquence, ce
dernier doit être installé sur le serveur OCS.

Première étape : obtenir un certificat pour le serveur WEB

Il est possible :
● d'acheter un certificat SSL 128 bits à un prix raisonnable aux alentours de 50.00$US/an. Voir
par exemple à cette adresse https://securityserver.org/.
● d'obtenir un certificat d'essai utilisable en environnement de test :
http://www.verisign.fr/ssl/buy-ssl-certificates/free-trial/
● de créer son certificat : c'est ce que nous nous proposons de faire... mais toute solution
opérationnelle sera acceptée

La documentation officielle d'OCS propose un script de génération de certificat à utiliser avec Apache
reproduit ci-dessous qui fonctionne parfaitement
http://wiki.ocsinventory-ng.org/index.php/Documentation:Teledeploy/fr :

#vi apache_generate_cert.sh

#!/bin/sh
#
# En premier, generer le certificat requis
#
# Generer une clé RSA de 1024 bits, enregistrer la cle privee dans un
# fichier PEM de mot-de-passe non protege server.key, en utilisant
# le fichier de configuration par defaut d'openssl
#
echo
echo Generation de la cle privee du serveur Apache...
echo
openssl genrsa -out server.key 1024
#
# Maintenant, signez le certificat du serveur Apache avec
# la cle du serveur Apache
#
# Signez avec le certificat PEM server.crt,
# en utilisant le fichier PEM server.key pour cle privee du server,
# en utilisant le fichier de configuration par defaut d'openssl.
#
# Le certificat produit sera valide durant 1825 jours (soit 5 ans).
#
echo
echo Generation des certificats auto-signes du serveur Apache ...
echo
openssl req -outform PEM -new -key server.key -x509 -days 1825 -out
server.crt

Ce script génère une clé privée RSA dans le fichier "server.key" et un certificat X.509 auto-signé dans
le fichier "server.crt".
Il faut maintenant :
● Mettre les droits d'exécution au script : chmod u+x apache_generate_cert.sh
● Lancer le script en utilisant cette commande : sh apache_generate_cert.sh

Celui-ci générera la clé privée, et vous demandera les propriétés du certificat :

• le code pays
• le nom de la province ou de l'état
• le nom de la ville

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 27/29

 • le nom de votre organisation
• le nom de votre section d'organisation
• le nom commun (le nom DNS ou l'adresse ip de votre serveur – très important – le
"CNAME" du certificat doit correspondre au nom du serveur OCS ou l'@IP telle qu'il
(elle) figure dans les fichiers de configuration – ça sera une adresse IP dans notre cas
(voir remarque ci-dessous))
• une adresse mél optionnelle

Attention : à priori et pour une raison que je ne m'explique pas, l'utilisation d'un FQDN dans le
certificat empêche le bon fonctionnement du télédéploiement (même si ce FQDN figure dans
les fichiers de configuration).

Deuxième étape : configurer Apache2 avec mod_ssl

Il est nécessaire de :
● Charger le module ssl avec l'utilitaire debian a2enmod en lançant la commande a2enmod ssl
dont le retour doit être du style : "Enabling module ssl. Run '/etc/init.d/apache2 restart' to
activate new configuration!" ; ce que l'on pourra faire plus tard car il y a d'autres modifications
à apporter.
L'activation du module a notamment pour effet d'activer le port d'écoute 443.
● Copier le fichier du certificat du serveur "server.crt" et le fichier de la clé privée "server.key"
dans les répertoires appropriés /etc/ssl/private/ :
#cp /root/server.* /etc/ssl/private/
● Mettre à jour les fichiers de configuration d'Apache2 pour utiliser ces fichiers
(/etc/apache2/sites-available/default-ssl ou tout autre fichier de configuration personnel) –
Attention, par mesure de précaution faîtes une copie de ces fichiers avant de les modifier.
Les 2 directives à modifier sont SSLCertificateFile et SSLCertificateKeyFile :
SSLCertificateFile /etc/ssl/private/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
● Activer (si ce n'est déjà fait) la nouvelle configuration : a2ensite default-ssl dont le retour doit
être "Enabling site default-ssl. Run '/etc/init.d/apache2 reload' to activate new configuration! "
● Redémarrez Apache2 : /etc/init.d/apache2 restart

L'URL : https://@IP|nom_dns|nom_serveur devrait maintenant vous renvoyer une page d'alerte de

sécurité ; ceci est normal car notre certificat n'a pas été signé par une autorité de certification connue.
Il suffit d'accepter l'exception. Mais il est bien évident que ce n'est pas une solution acceptable en
environnement de production...

Troisième étape : copier le certificat sur chaque client

L'agent doit avoir un certificat pour valider l'authentification au serveur de déploiement. Il s'agit
du fichier server.crt. Ce certificat doit être enregistré dans un fichier "cacert.pem" dans le répertoire de
l'agent OCS Inventory NG sous Windows et dans le répertoire "/etc/ocsinventory" sous Linux.

Il vaut mieux renommer ce certificat sur le serveur (cp server.crt cacert.pem) avant de le copier
sur chaque client Windows car si sur ce dernier la visibilité des extensions n'est pas activée le certificat
aura pour nom "cacert.pem.crt" et l'authentification ne pourra pas se faire.

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 28/29

Annexe A : tableau d'aide à la décision

Questionnement de l'administrateur réseau Réponses

AVANT LA MISE À JOUR DES TAGS
Il y a encore quelques salles informatiques du lycée où l'agent n'est pas
installé sur les postes. Quel est le nombre de machines
automatiquement remontées (sur les 450 du parc) ?
Le lycée voudrait équiper chaque salle d'enseignement général (au
nombre de 28) d'un poste informatique pour que chaque professeur
puisse saisir les absences. Compte tenu du coût que cela
représenterait, il a été décidé de recycler des machines devenant
obsolètes au niveau pédagogique. À cette fin, il faudrait comptabiliser le
nombre de machines ayant entre 128 MB et 1024 MB (compris) de
mémoire vive.
Y a t-il un antivirus installé sur les postes n'ayant pas été intégrés au
domaine LLB ? Les antivirus au lycée sont Avast et Microsoft Security
Essential.
À des fins d'homogénéisation des logiciels du parc, il faut connaître les
différentes versions d'OpenOffice et de Microsoft Office.
Afin de vérifier les licences, recherchez les postes ayant une version de
Microsoft Office 2007 et de Microsoft Office 2010 puis mettez-les dans
le groupe statique adéquat préalablement créé.
OCS est capable de détecter un ordinateur renommé, réinstallé, …
Généralement, il se débrouille tout seul. Mais parfois, il est impossible
au serveur de savoir que deux ordinateurs sont identiques ou non, par
exemple quand le numéro de série n'est pas proprement paramétré par
le constructeur (si vous changez le nom d'un ordinateur, l'application ne
sera pas capable de le reconnaître s'il n'y a pas de numéro de série,
elle dupliquera l'ordinateur). Combien de doublons sont recensés dans
le parc ?

Pour quelles raisons le système les considère-t-il comme des

doublons ?

Proposez une action pour chaque doublon trouvé.

APRÈS LA MISE À JOUR DES TAGS

La salle 201 des BTS CGO doit pouvoir accueillir 17 étudiants. Le
nombre de machines est-il suffisant ?
Une des conditions pour pouvoir installer XenClient (outil permettant la
virtualisation des postes de travail) porte sur les processeurs qui doivent
être de marque "Intel". Les postes de la salle 200 remplissent-ils cette
condition ?

http://www.reseaucerta.org © CERTA - octobre 2015 – v3.0 Page 29/29