Référentiel des locaux techniques avec

RackTables
Fabien Priotto
Direction du Système d’Information et du Numérique
Service des moyens informatiques (infrastructures)
UNIVERSITÉ DE MONTPELLIER
CC 427 – Espace Richter – Rue Vendémiaire – Bât. B – CS 19519
34 960 Montpellier Cedex 2
https://www.umontpellier.fr

Résumé
L’Université de Montpellier n’échappe pas à la mode des bases de données de gestion de
configuration (CMDB) qui visent à donner une vue d’ensemble sur les actifs logiciels et matériels
du SI.
Dans cette perspective, RackTables est une solution libre et gratuite. Basée sur une architecture
LAMP, elle permet d’établir l’inventaire des locaux techniques. Cette technologie se révèle à la
hauteur de sa tâche, mais nous autres, insatiables humains et néanmoins collègues, exigeons
toujours plus de confort et de facilité.
Des outils maison sous forme de plugins viennent donc compléter RackTables :
• RackMaps pour géolocaliser les bâtiments dans les cartes Google et OpenStreetMap,
• RackReports pour vérifier d’un coup d’œil le nommage des divers objets référencés,
• RackArchives, pour faciliter l’accès aux documents archivés notamment les images.
Nous répertorions aujourd’hui plus de 400 baies, 290 locaux, 300 commutateurs et 600 tiroirs
optiques sur 6 villes et 22 sites. Les matériels sont référencés selon le triptyque fondamental à
RackTables (Location / Row / Rack) : une localisation (bâtiment avec ses coordonnées GPS), un
local (local technique, placard, bureau, gaine technique, etc. ) et une position dans une baie.
Avec un accès restreint pour l’instant aux quelques agents du service des infrastructures de la
DSIN, via une authentification Radius, notre usage de RackTables se heurte déjà à un cruel
constat : les évolutions matérielles vont bon train et l’inventaire ne reste pas à jour. Nous
évoquerons donc en fin de présentation quelques pistes pour tenter de remédier à ce problème
crucial pour la qualité de notre cher référentiel...

Mots-clefs
RackTables, CMDB, référentiel, matériel, inventaire, opensource

1 Prologue
Il fut un temps où les ingénieurs et techniciens informaticiens de nos universités, éparpillés dans les
nombreuses composantes, ne connaissaient pas, ou si peu, de directions informatiques.
Les échanges entre confrères étaient plus ou moins organisés. Parfois existait-il un centre de
ressources informatiques pour le partage des connaissances. Les administrateurs systèmes et

JRES 2021 – Marseille 1/16

réseaux, nichés au fond de leur bureau encombré de livres O’Reilly 1 ainsi que de moult objets
technologiques détenaient les clés du parc informatique, celles des locaux techniques, et toute la
connaissance nécessaire à la gestion de l’infrastructure réseau de leur composante.
On trouvait dans chaque unité, un informaticien capable d’accéder à l’interface des éléments
réseaux et de les configurer. Le référent réseaux, comme on se plaisait à le qualifier, était souvent
aperçu, quelques câbles de catégorie 5 sous la main, s’en allant gaiement brasser des prises RJ45 au
bonheur des usagers qui ne manquaient pas de le remercier. Dans son quotidien d’informaticien, usé
par trop d’activités abstraites et sédentaires, ces petites balades constituaient une parenthèse plutôt
bénéfique à sa santé. Mais le métier avait commencé à changer et la tendance était déjà à la
centralisation des compétences. Une vague de fusion universitaire visant à défragmenter
l’organisation de l’enseignement supérieur fut engagée.

2 Où l’on parle d’inventaire

A Montpellier, les universités UM1 et UM2, toutes deux héritières de l’université historique, se
marièrent le 1er janvier 2015 pour le meilleur et pour le pire. Une harmonisation centralisée des
services informatiques pour les UFR fut envisagée et l’université chercha à se munir de bases de
données de gestion de configuration (CMDB) afin de disposer d’une vue d’ensemble sur les actifs,
qu’ils soient matériels ou logiciels, de son SI.
Une fois en place, la direction de la toute nouvelle et grande université décida d'intégrer les services
informatiques de composantes à la DSIN et de muter ledit référent réseaux dans un bureau de
spécialistes. Dès son arrivée, on somma le nouveau venu de prendre en charge l’inventaire des
locaux techniques de l’ensemble de l’université, c’est-à-dire de répertorier des centaines de
matériels, disséminés sur les multiples sites dans plusieurs villes de la région.
Perplexe face à cette mission, la première difficulté fut de trouver les moyens pour relever un tel
défi tant les données à collecter semblaient nombreuses et éparses.

2.1 Y’a quelqu’un ?

Un beau matin, notre protagoniste s’en alla fouiller dans les archives des JRES ainsi que dans les
échanges entre membres du CSIER2 dans l’espoir de trouver les traces de quelques semblables qui
auraient trouvé une solution au problème. Il consultait quelques retours d’expérience tels que
l’usage de GLPI avec ou sans FusionInventory [1], quelques outils maison tels que GRIP [2] quand
la solution RackTables3 apparut comme un soleil.

2.2 De vieux amis

Qu’il est agréable de découvrir l’existence d’une solution qui en plus d’être disponible et gratuite
permet de retrouver de vieux amis. RackTables est une solution Opensource qui peut être hébergée
sur une infrastructure LAMP. Plus qu’un acronyme, nous parlons là d’une relation durable. Linux,
Apache, MySQL et PHP, quatre composants technologiques qui ont pris tant de place dans une
carrière ou il faut sans cesse bricoler des solutions Web sans jamais disposer de moyens financiers
ni de temps. Il fut assez simple et rapide de tester une instance de RackTables et d’en découvrir les
fonctionnalités.

1 À l'origine exclusivement centrés sur l'administration et la programmation des systèmes Unix, les livres publiés par
O'Reilly couvrent en 2005 tous les domaines de l'informatique.
2 https://www.csiesr.eu
3 https://www.racktables.org/

JRES 2021 – Marseille 2/16

2.3 RackTables

Figure 1: page d'accueil de la démonstration en ligne de RackTables

Le site officiel présente RackTables comme une solution astucieuse et robuste pour la gestion des
actifs des centres de données et des salles de serveurs. Elle fut fondée en 2006 par Denis Ovsienko
et est maintenue sous licence GPL.
Le nom "RackTables" vient de la motivation initiale du logiciel : remplacer un ensemble de
descriptions de racks qui étaient alors stockées dans un wiki. Le but du tout premier script était de
générer, à l’identique pour ces racks, des tables HTML à partir de MySQL. Puis l’application a
évolué grâce à la collaboration active d’une petite communauté animée par les auteurs du projet
férus d’administration systèmes et réseaux. Ils savent par expérience que pour des centaines de
serveurs, de commutateurs, des milliers d'adresses IP, de nombreux équipements éparpillés dans des
centres de données, des locaux techniques et des bureaux, il n’est pas sérieux d’envisager
l’inventaire avec un simple tableur.
2.3.1 Pas d’inventaire sans dictionnaire

Avec RackTables, nous disposons d’une interface pour identifier et accéder à une description des
différents objets (OBJECTS) selon un triptyque fondamental : les localisations (LOCATIONS),
les locaux (ROWS) et les baies (RACKS).
Les types d’objets sont définis dans le chapitre ObjectType du dictionnaire qui peut facilement être
édité. Chaque instance de RackTables possède son propre dictionnaire (Main page : Configuration :
Dictionary) qu’il convient d’étudier avec de commencer les saisies car c’est là que sont définis non

JRES 2021 – Marseille 3/16

seulement les types d’objets mais aussi les modèles de matériels.La ligne suivante est un exemple
pour l’ajout d’un modèle de commutateur dans le chapitre network switch models :
[[Cisco%GPASS%Nexus 5000 | https://www.cisco.com/c/en/us/products/switches/nexus-5000-series-
switches/index.html]]

Figure 2: chapitre ObjectType dans le dictionnaire pour une instance RackTables

JRES 2021 – Marseille 4/16

En termes de SGBD, localisations, locaux et baies constituent des vues de données stockées dans
une base MySQL. La description SQL de ces vues sera donnée en annexe de cet article.
Du côté de PHP, sans pénétrer dans les profondeurs du code de RackTables, nous disposons d’une
API REST pour rechercher chacun des éléments susceptibles de nous intéresser : locations, rows,
racks, fichiers etc. Conçue pour les recherches, cette API permet de manipuler les expressions
spécifiques à RackTables (les !RackCode expressions4) que nous n’aborderons pas dans cet article.
Retenez simplement qu’avec RackTables, on dispose d’une parade pour éviter les douleurs de SQL
si l’on souhaite scripter des sélections sur les différents champs de RackTables.5
Un index MySQL est disponible pour les divers types d’éléments : objtype_id. Nous verrons plus
loin que cela est intéressant pour l’ajout de modules complémentaires à RackTables quand on sait
que les objets de type location, row et rack correspondent respectivement aux identifiants 1560,
1561 et 1562 tels que définis par défaut dans le dictionnaire.
2.3.2 Rack

Figure 3 RACK: description d’un coffret

de 8 unités
C’est une vue de profil que nous propose RackTables pour la présentation des racks avec une
division en trois colonnes (Face/Intérieur/Arrière), chaque ligne comptant pour une unité
dimensionnelle, soit 44,45 mm de hauteur.
Le mode de saisie par défaut des données se fait via un formulaire depuis un navigateur, mais nous
verrons plus loin qu’il est heureusement possible de procéder à des importations. Notez au passage
si vous en doutiez que le terme « rack » est un anglicisme aujourd’hui reconnu chez Larousse et
Robert.

4 https://wiki.racktables.org/index.php/RackTablesDevelGuide#RackCode
5 https://wiki.racktables.org/index.php/RackTablesDevelGuide#Realms

JRES 2021 – Marseille 5/16

2.3.3 Row

Figure 4: ROW: description d’un local technique hébergeant une baie

La représentation des locaux prend la forme d’un résumé accompagné d’une vue réduite de chacun
des racks contenus dans le local. À Montpellier, nous désignons plusieurs types de locaux : salle
serveurs (SS), local technique (LT), local pour le rangement (LPR), gaine technique (GT), coffret
dans un espace publique (CO), placard (PL).
Notez au passage la fonctionnalité de Tag qui offre la possibilité de classer les objets avec un petit
effet de couleur.

JRES 2021 – Marseille 6/16

2.3.4 Location

Figure 5: LOCATION: description d’un site regroupant 2 bâtiments

Figure 6: LOCATION: description d'un bâtiment contenant un local technique

Les sites et les bâtiments sont tous référencés en tant que localisations (locations). Nous les
nommons selon le référentiel de la direction du patrimoine. En ce qui concerne les locaux (Rows), la
direction du patrimoine a effectué un étiquetage précis que nous reportons dans RackTables (noms
des sites, des bâtiments et numéro des salles).
Un site est une localisation mère. Dans notre référentiel montpelliérain, le nom d’un site commence
par un numéro et celui d’un bâtiment commence par le nom de sa localisation mère. Cette
convention est intéressante pour la cartographie. Ainsi, dans la figure 5, le site 05.CSU contient un
bâtiment CSU-C au rez-de-chaussée duquel se trouve un local technique LT-CSU-00-57.0.
Quelques lignes de codes insérées dans le fichier inc/interface.php de la distribution RackTables
permettent de modifier la fonction renderLocationPage($location_id) et d’ajouter des clés au
tableau summary pour y insérer des références dynamiques. Cela peut permettre d’ajouter quelques
hyperliens dans la description des localisations.
$summary['Location']="<a href='/index.php?page=rackspace&tab=maps&loc=".$locationData['name']."'>".
$locationData['name'] ."</a>";

JRES 2021 – Marseille 7/16

Cette ligne de code ainsi ajoutée fait référence à l’onglet « maps » de la page « Rackspace » dont
nous reparlerons plus loin.
Notez cette façon de modifier l’interface de RackTables car nous verrons au chapitre 3.3 qu’à défaut
de plugin disponible, celle-ci nous permettra d’ajouter un élément essentiel à notre référentiel !

2.4 Quand faut y aller

RackTables en main, nous retrouvons notre gestionnaire réseau en possession d’un outil efficace et
c’est confiant qu’il se lance dans sa mission. Mais où aller ? À qui s’adresser ? Rapidement, il
comprend qu’il lui sera nécessaire de cartographier les locaux de l’université avant de se lancer
dans l’inventaire.
2.4.1 Google Location

De son passage il y a quelques années en laboratoire de Recherche, notre chargé d’inventaire, qui
n’en demeure pas moins un programmeur, avait conservé quelques lignes de code de divers
développements. En termes de cartographie, ce fut assez rapide pour lui de mettre en action l’API
JavaScript de la Google Maps platform6.
Cette librairie permet de personnaliser les cartes pour les afficher sur des pages Web et des appareils
mobiles. Et c’est au bout d’environ 600 lignes d’un code fonctionnel JavaScript que la solution
Google Location vit le jour.

Figure 7: Google Location, localisation avec JavaScript Google Maps API

Le référencement peut ainsi commencer avec l’aide d’une carte interactive à laquelle quelques
fonctionnalités sympathiques sont rapidement ajoutées. Citons ici la recherche dynamique des
lieux (librairie Places), la géolocalisation (GeoLocation API), l’importation de données GeoJSON
(par exemple la description des nœuds de raccordement FTTH publié par le gouvernement) ou
encore un presse-papiers pour copier les coordonnées GPS.
Mais la nouvelle tombe : La politique tarifaire de Google vient de changer et l’administration de
l’université renonce à utiliser ses services ! Il faut vite se libérer et trouver une nouvelle fois refuge
dans l’Open source.

6 https://developers.google.com/maps

JRES 2021 – Marseille 8/16

2.4.2 Open Location

Pas tout à fait surpris par une telle manœuvre commerciale du groupe au monopole, le développeur
Web, qui a plus d’un tour dans son sac, migre rapidement son application vers une librairie gratuite.
C’est ainsi que le projet Open Location et son petit kilo de lignes de code propulsé par les librairies
gratuites OpenLayers 7en version 5 prend place.

Figure 8: Open Location, localisation avec les librairies OpenLayers

A ce moment, notre préposé à l’inventaire n’a plus qu’à intégrer ses petits applicatifs de
cartographie à la solution RackTables. Ce fut fait au prix d’un peu de lecture du guide de
développement en ligne8 fourni par les disciples de saint Denis Ovsienko sous la forme d’un plugin.
2.4.3 RackMaps

La version 0.21.0 de RackTables introduit une nouvelle architecture de modules d’extension, qui
inclut la possibilité d'installer, de désinstaller, d'activer et de désactiver des outils complémentaires à
partir de l'interface Web 9. Chaque module réside dans son propre répertoire et fournit un fichier
plugin.php qui inclut les fonctions d’information, installation, suppression et mise à jour du plugin.
Ce design a été inspiré par l'architecture des plugins de Cacti. C’est sur ce modèle que les
applications Google Location et Open Location se retrouvent intégrées à RackTables sous couvert
du plugin nommé RackMaps.

7 https://openlayers.org/
8 https://wiki.racktables.org/index.php/RackTablesDevelGuide
9 https://wiki.racktables.org/index.php/Plugins

JRES 2021 – Marseille 9/16

 Figure 9: RackMaps, intégration des localisations dans un onglet Maps.

Figure 10: les outils complémentaires sous forme de modules d'extension de RackTables

3 Quand on te demande où en est l’inventaire

Après moult visites sur sites, notre chargé d’inventaire rapporte de précieuses informations. Mais
comment nommer ces matériels sur lesquels ne se trouve hélas pas toujours une jolie étiquette ? Il
s’avère rapidement nécessaire de garantir un suivi du nommage des matériels dans RackTables sans
quoi on ne s’y retrouve plus.
Puisque le référentiel a démarré par l’inventaire des matériels réseaux, il serait naturel de se référer
à SNMP. D’autant plus qu’il est possible de faire des requêtes directement depuis RackTables via
l’Onglet SNMP Sync Racktables. Mais interroger depuis un serveur Web des matériels actifs du
réseaux pose quelques difficultés notamment en termes de topologie. De fait, un petit outil pour
contrôler les noms d’objets s’avère bien utile.

3.1 RackReports
Nous avions signalé au chapitre 2.3 qu’un index MySQL était disponible pour identifier les
différents types d’éléments : objtype_id. C’est cet identifiant qui va permettre des faire le tri parmi
les multiples objets référencés. Puisque les requêtes SNMP ne sont pas toujours possibles, il ne reste
plus qu’à ranger dans une liste les noms d’usage pour chacun des divers matériels et de vérifier pour
chacun qu’il soit correctement enregistré dans la base de données de RackTables.

JRES 2021 – Marseille 10/16

Établir un rapport selon des listes de nom d’objets pré-établies, c’est cela que nous aide à accomplir
le plugin RackReports. Une fois celui-ci installé, il suffit de déposer sur le serveur Web pour
chaque type de matériel un dossier contenant les listes de noms que l’on souhaite valider.
L’interface utilisateur de RackTables permet de configurer la variable RACKREPORTS_OBJTYPES
pour cibler les différents types de matériels qui nous intéressent en précisant le fameux objtype_id
dont nous parlions précédemment. Notez que cet identifiant est fixé par le dictionnaire de
RackTables. Notez aussi que le type de matériel donne en même temps le nom du dossier (switches,
multiplexers etc.) dans lequel les listes de noms sont enregistrées.
Accessible via l’interface utilisateur, la variable suivante renvoie aux dossiers switches et
multiplexers qui contiennent les listes des noms à vérifier.

Figure 11: variable RACKREPORTS_OBJTYPES vue depuis l'interface utilisateur de RackTables

Figure 12: RackReports, des rapports sur les noms d’objets depuis l’onglet CheckedReport de la
page Reports dans RackTables
Ainsi, un bon référentiel exige une identification minutieuse des matériels et cela se fait notamment
grâce aux photos et vidéo prises sur le terrain qu’il est bon de stocker sous formes d’archives
accessibles directement depuis RackTables.

JRES 2021 – Marseille 11/16

3.2 RackArchives
Ce n’est pas la peine de réinventer la poudre : parcourir une arborescence du côté serveur est un
besoin courant dans l’usage du Web. Il doit bien exister un code disponible et suffisamment abouti
pour s’acquitter de cette tâche.
Le choix se porte rapidement sur DirectoryLister10 dans une sa version 2.7.1 qui offre une
performance acceptable notamment au moment du scan de l’arborescence contrairement aux
version 3+. Ce détail a son importance car nous parlons là d’une arborescence assez lourde
puisqu’il s’agit des multiples photos et vidéo qui s’accumulent au fil de l’inventaire dans une
organisation hiérarchique à 3 niveaux: Site > Bâtiment > Local

Figure 13: RackArchives, pour l'accès aux documents archivés

Les locaux sont à présent inventoriés, les matériels localisés et documentés mais il manque un
élément essentiel pour établir le lien concret entre matériel et référentiel. Vous voyez lequel ?
Il manque l’étiquetage, ce petit bout d’information, une méta-donnée qui reliera les matériels à
l’object_id affecté lors de leur saisie dans RackTables. Ce sera un QR-code.

3.3 QR-code
La fonction renderObject disponible dans le fameux fichier inc/interface.php de la distribution
RackTables détermine la vue pour un objet et prend en paramètre d’entrée l’identifiant de cet objet.
L’insertion des 2 lignes de code ci-dessous dans cette fonction permet de faire appel à une API en
spécifiant la valeur de l’identifiant (le fameux object_id d que nous mentionnâmes à la fin du
chapitre 2.3 ). Notez au passage l’encodage UTF-8 de l’URI pour la variable qrcodeURL.
$qrcodeURL = API_QR_CODE . MY_URL . "/index.php%3Fpage=object%26object_id=" . $object_id;
echo "<tr><td class=pcright><a href=". $qrcodeURL . "><img src=" .$qrcodeURL ."></a></td></tr>";

A Montpellier, nous utilisons l’API Quickchart11 mais ce n’est qu’indicatif et il suffit de définir la
constante API_QR_CODE dans une petite ligne de code à placer en début du fichier
inc/interface.php.
define("API_QR_CODE","https://quickchart.io/qr?text=");

10 hhttps://www.directorylister.com/
11 https://quickchart.io/

JRES 2021 – Marseille 12/16

 Figure 14: QR-code associé à un commutateur
On obtient ainsi la possibilité d’étiqueter les matériels avec un joli QR-code qui renvoie vers la page
de description de l’objet référencé dans RackTables. Et on peut faire les modifications similaires
pour les localisations, les locaux et les baies dans le corps des fonctions renderLocationPage,
renderRow et renderRackPage en prenant soin d’adapter le nom de l’identifiant (location_id,
row_id et rack_id).

4 Qui vivra verra

Avec RackTables, quelque soit leur niveau de connaissance terrain, les administrateurs systèmes et
réseaux bénéficient d’une vue d’ensemble sur le matériel accompagnée des informations pratiques.
On l’a vu, les possibilités pour adapter RackTables aux besoins spécifiques d’un établissement sont
nombreuses et souvent gratuites. Cela fait de RackTables un outil pratique, gratuit et performant.
Encore faut-il s’accorder sur la manière de l’utiliser.
A Montpellier, l’avenir du référentiel DSIN est dans les mains des agents du service des moyens et
infrastructures. C’est de leur volonté que dépendra la maintenance de l’application et de ses
données pour que RackTables constitue un réel atout dans la gestion des actifs (Asset Managment).
Hors dans notre vaste et vieille université, les évolutions matérielles vont bon train et l’inventaire ne
reste pas à jour. Son suivi constitue une contrainte supplémentaire et demande de sensibiliser les
agents ce qui est le rôle des responsables d’équipes. Un gestionnaire d’application ne peut que
suggérer des solutions dans l’espoir de faciliter la tâche. Voyons ensemble quelques pistes.

4.1 Import CSV

L’importation de données est une piste intéressante : elle consisterait à collecter à chaque
modification, suppression ou ajout de matériel, l’ensemble des informations permettant une mise à
jour de RackTables sous la forme d’une ligne CSV.
Il existe le plugin CSV Import tool dans la distribution Racktables-contribs12. Le format de cette
ligne dépend du type de modification effectuée.
4.1.1 Import CSV pour l’ajout de matériel

Pour l’ajout d‘un nouveau matériel, il faut saisir la ligne suivante:

OBJECT;OBJECT_TYPE;COMMON_NAME;VISIBLE_LABEL;ASSET_TAG;

12 https://github.com/RackTables/racktables-contribs

JRES 2021 – Marseille 13/16

Valeur 1: OBJECT (mot clé invariable)
Valeur 2: Object_type (chaîne de caractères ou une valeur numérique) indique le
"Object type" dans RackTables (Cf. Configuration : Dictionary : Chapter
'ObjectType')
Valeur 3: Common_name (chaîne de caractères)
Valeur 4: Visible_label (chaîne de caractères)
Valeur 5: Asset_Tag (chaîne de caractères)
Valeur 6: Tableau Optionnel Ports séparés par une virgule. Ex. 'eth[0-9]' . Le
champs "tableau Port type" doit aussi être renseigné.
Valeur 7: Tableau Port Type de la forme a-b où a est le type d'interface interne
et b le type d'interface externe. a et b sont des valeurs numériques. (Cf. Main
page:Configuration: port types).
4.1.2 Import CSV pour localiser un matériel

Pour localiser dans un rack un nouveau matériel, il faut saisir la ligne suivante:
RACKASSIGNMENT;COMMON_NAME;RACK_NAME;UNITS_LIST;INDICATIONS_LIST

Valeur 1: RACKASSIGNMENT (mot clé invariable)

Valeur 2: Common Name (chaîne de caractères)
Valeur 3: Rack Name (chaîne de caractères)
Valeur 4: liste des numéro d'unités occupées (séparés par une virgule).
Valeur 5: liste des indications (séparées par une virgule) concernant les
secteurs (avant, intérieur, arrière) occupés par l'objet. Les indications sont
données les lettres suivantes: f pour Front, i pour interior, b pour back.
Notez que le nom de chaque baie (racks) doit être unique dans RackTables pour que cette procédure
via import CSV soit possible. Cette contrainte est lourde puisqu’il faut veiller à une unicité parfaite
des noms. Concrètement sur le terrain, ça veut dire modifier les centaines d’étiquettes que l’on
trouve très souvent sur les portes des baies réseaux et qui dans les faits s’intitulent quasiment
partout BAIE 1, BAIE 2, etc. Du coup, il faut décider d’utiliser ou pas cette méthode avant de
collecter les informations sous peine de devoir repasser sur toutes les baies pour l’étiquetage.

4.2 Le travail collaboratif

Si les procédures de mise à jour via imports CSV s’avèrent impossibles, il reste encore la possibilité
aux collègues de contacter directement le gestionnaire RackTables à chaque fois qu’une
modification est effectuée sur le matériel inventorié. Il serait alors sage d’utiliser quelques
formulaires de saisie pré-établis selon le type d’opération pour s’assurer que toutes les informations
nécessaires soient effectivement communiquées.
On peut aussi souhaiter que le maintien à jour des données de RackTables soit le fruit d’un travail
collaboratif. Un premier tour de table à propos de l’expérience avec RackTables au sein de notre
bureau de spécialistes Réseaux laisse à penser que les modifications et les ajouts se feront au fil des
opérations par les collègues sous le contrôle automatisé du gestionnaire de l’application notamment
grâce au plugin RackReports. Voyons à présent les possibilités d’authentification qui s’offrent aux
utilisateurs.
4.2.1 Authentification locale

C'est la méthode la plus ancienne. Les hachages de mot de passe sont stockés dans la base de
données SQL avec toutes les autres données. RackTables vérifie les mots de passe lui-même.
Cette méthode d’authentification s’active par la ligne suivante dans le fichier inc/secret.inc :
$require_local_account = TRUE;

JRES 2021 – Marseille 14/16

4.2.2 Authentification externe

Dans ce mode, RackTables s'assure uniquement que l'utilisateur soit valide. Il faut que le serveur
Web qui héberge RackTables soit configuré pour garantir la redirection vers un service
d’authentification.
Cette méthode s’active par les lignes suivantes dans le fichier inc/secret.inc:
$user_auth_src = 'httpd';
$require_local_account = FALSE;

RackTables est compatible avec les méthodes d’authentification htpasswd, Radius, LDAP, Kerberos
et Shibboleth. Tout ceci est bien documenté dans le guide à l’administration en ligne 13.

5 La cause d’Inventaire
Un bon référentiel constitue un outil stratégique de traçabilité. L’inventaire est une préoccupation
technique. Il exige de visiter des locaux parfois peu accessibles, de localiser des appareils qu’il n’est
pas toujours évident de distinguer, une gestion logicielle voire quelques développements spécifiques
et une mise à jour des données au fil des mouvements de matériels. Chaque établissement verra bien
de quelles forces en présence il dispose et saura fixer son propre niveau d’ambition. A Montpellier,
dans notre université, il est trop tôt pour faire une réelle évaluation des gains mais un rapide tour de
table auprès des collègues semble indiquer que RackTables est salutaire pour préparer les opérations
de terrain. Il est important de souligner que la pérennité de cette solution dépendra de l’effort
collaboratif dans la saisie des données au fil de l’eau sous peine de vite devenir obsolète. En étant
optimisme, on peut espérer que les collègues adopteront la bonne manière pour contribuer et nous
pourrons parier que les prestataires d’infogérance, qui ne manqueront pas de se positionner sur le
marché de l’enseignement supérieur, apprécieront de disposer d’un tel outil.

13 https://wiki.racktables.org/index.php/RackTablesAdminGuide#User_authentication

JRES 2021 – Marseille 15/16

6 Annexes
Description des vues SQL qui nous intéressent dans le chapitre 2.3 :
RACK:
select `o`.`id` AS `id`,`o`.`name` AS `name`,`o`.`asset_no` AS `asset_no`,`o`.`has_problems` AS
`has_problems`,`o`.`comment` AS `comment`,`av_h`.`uint_value` AS `height`,`av_s`.`uint_value` AS
`sort_order`,`rt`.`thumb_data` AS `thumb_data`,`r`.`id` AS `row_id`,`r`.`name` AS
`row_name`,`l`.`id` AS `location_id`,`l`.`name` AS `location_name` from
(((((((`racktablesprep`.`object` `o` left join `racktablesprep`.`attributevalue` `av_h`
on(((`o`.`id` = `av_h`.`object_id`) and (`av_h`.`attr_id` = 27)))) left join
`racktablesprep`.`attributevalue` `av_s` on(((`o`.`id` = `av_s`.`object_id`) and (`av_s`.`attr_id`
= 29)))) left join `racktablesprep`.`rackthumbnail` `rt` on((`o`.`id` = `rt`.`rack_id`))) left join
`racktablesprep`.`entitylink` `rl` on(((`o`.`id` = `rl`.`child_entity_id`) and
(`rl`.`parent_entity_type` = 'row') and (`rl`.`child_entity_type` = 'rack')))) join
`racktablesprep`.`object` `r` on((`r`.`id` = `rl`.`parent_entity_id`))) left join
`racktablesprep`.`entitylink` `ll` on(((`r`.`id` = `ll`.`child_entity_id`) and
(`ll`.`parent_entity_type` = 'location') and (`ll`.`child_entity_type` = 'row')))) left join
`racktablesprep`.`object` `l` on((`l`.`id` = `ll`.`parent_entity_id`))) where (`o`.`objtype_id` =
1560)

ROW:
select `o`.`id` AS `id`,`o`.`name` AS `name`,`l`.`id` AS `location_id`,`l`.`name` AS
`location_name` from ((`racktablesprep`.`object` `o` left join `racktablesprep`.`entitylink` `el`
on(((`o`.`id` = `el`.`child_entity_id`) and (`el`.`parent_entity_type` = 'location') and
(`el`.`child_entity_type` = 'row')))) left join `racktablesprep`.`object` `l`
on(((`el`.`parent_entity_id` = `l`.`id`) and (`l`.`objtype_id` = 1562)))) where (`o`.`objtype_id` =
1561)

LOCATION :
select `o`.`id` AS `id`,`o`.`name` AS `name`,`o`.`has_problems` AS `has_problems`,`o`.`comment` AS
`comment`,`p`.`id` AS `parent_id`,`p`.`name` AS `parent_name` from (`racktablesprep`.`object` `o`
left join (`racktablesprep`.`object` `p` join `racktablesprep`.`entitylink` `el`
on(((`el`.`parent_entity_id` = `p`.`id`) and (`p`.`objtype_id` = 1562) and
(`el`.`parent_entity_type` = 'location') and (`el`.`child_entity_type` = 'location'))))
on((`el`.`child_entity_id` = `o`.`id`))) where (`o`.`objtype_id` = 1562)

Bibliographie
[1] Ludovic Hyvert Emmanuel Le Normand - FusionInventory, le nouveau duo de la gestion de
parc !, 2013. https://2013.jres.org/archives/148/paper148_article.pdf
[2] Pascal Mouret Clément Gérardin - Un outil open source de gestion de l'infrastructure physique
des réseaux informatiques , https://2013.jres.org/archives/156/paper156_article.pdf

JRES 2021 – Marseille 16/16