La gestion de parc à « Lille 2 » Solution basée sur les logiciels libres Max LAMBERT – Min2Rien – 25 Janvier 2018

I - Ecosystème

L’environnement de notre SI Les postes clients : Majoritairement sous windows 7 64. Les utilisateurs s’identifient sur un domaine SAMBA. Les « homes » sont réparties géographiquement sur plusieurs serveurs. Les serveurs : SAMBA 3.6.6 sur des serveurs Debian 7 (machines virtuelles sous KVM) Le stockage : Baies EqualLogic.

II - Cycle de vie des machines Les achats

Les achats Exclusivement dans le marché MATINFO (sauf exceptions VIP et postes spécifiques) Les devis sont réalisés par les services de proximité. Des configurations « type » sont élaborées. Les grandes lignes sont : - Garantie à 5 ans (pour faire coïncider l’amortissement comptable et la durée de vie) - Système d’exploitation standardisé : Windows 7 64 actuellement (mais achat de Windows 10 avec downgrade) - Matériel standardisé (SSD SATA plutôt que M2 PCIe par exemple).

Pourquoi ces standardisations ? Un matériel en production est garanti : Un dysfonctionnement matériel est toujours couvert par la garantie constructeur : le délai d’immobilisation pour intervention technique est donc limité. Un matériel de remplacement est mis en place avec un minimum de personnalisation pendant ce délai. Simplicité masterisation accrue. - Un seul système d’exploitation = une image et peu de variations sur le paramétrage des applications. - Toutes les configurations proposées ne disposent pas du M2 PCIe.

II - Cycle de vie des machines L’inventaire

L’inventaire informatique Différent de l’inventaire comptable : Les informations comptables ne sont pas suffisantes pour l’exploitation. Il est nécessaire de connaître (à minima) l’adresse physique pour le DHCP par exemple. Réalisé automatiquement par un agent local : Fusion inventory qui injecte ses données dans GLPI. L’inventaire informatique n’est réalisé qu’après l’inventaire comptable : L’inventaire informatique n’est réalisé que sur le matériel de l’université. C’est l’inventaire comptable qui valide l’achat (et donc la propriété) du matériel.

II - Cycle de vie des machines L’exploitation

L’exploitation Validation de la configuration : Les configurations recommandées sont testées (avant recommandation) pour s’assurer une parfaite maîtrise technique. Préparation du « master » : Un poste « patient zéro » est paramétré en lui appliquant les restrictions permettant l’utilisation optimale dans notre environnement sans perte de fonctionnalité pour les applications « métier ». Enregistrement de l’image sur notre serveur de diffusion FOG.

FOG Architecture de FOG.

FOG Pourquoi cette architecture « multi-serveurs » ? Ne pas utiliser la connexion inter-site (débit « faible » ) Placer les serveurs au plus près des utilisateurs lors des déploiements (pour ne pas engorger les réseaux) Le boot utilise PXE (on évite les broadcast sur l’ensemble du réseau) Autonomie de chaque site (pour s’adapter aux besoins spécifiques)

FOG Pourquoi centraliser la Base de données ? : Diminuer les coûts (temps homme) de la maintenance (une seule ressource humaine, non exclusive, pour l’assurer) Rationaliser l’environnement (cohérence des informations) Centraliser les données statistiques et techniques stockées dans la base

FOG Avantages de FOG : - Interface web de gestion centralisée - Gestion des utilisateurs « par site » et gestion de groupes de machines - Déploiement d’OS - Déploiement de logiciels (snapin) - Multicast - Jonction au domaine après déploiement - ...

FOG Limtations de FOG : - Seulement deux profils d’utilisateur « regular » : toutes fonctions « mobile » : interface simplifiée et déploiement limité - Le noyau PXE doit être mis à jour lorsque certains nouveaux matériels arrivent sur le réseau. Donc, les coûts (temps homme) de maintenance des serveurs augmente et il y a un risque de maintenir plusieurs versions sur les différents sites. - Les images sont dépendantes du matériel (sauf à inclure de nombreux pilotes ‘inutiles’ dans les images, solution que nous n’avons pas retenue pour diminuer le temps de diffusion)

Notre utilisation de FOG Masterisation complète pour les salles de TD : - OS mis à jour, solution logicielle complète - Multiplication des images pour répondre aux différents usages - Déploiement multicast privilégié Masterisation minimale pour les postes des personnels : - OS avec un minimum d’outils (bureautique, …) et le déploiement des logiciels par « snapin ».

Création et utilisation des « snapin » Types de Snap-in gérés par FOG : - EXE - MSI - Batch Script - Bash Script - VB Script - Powershell Nous utilisons généralement InstallRite (Gratuiciel) pour la création de fichiers exécutables qui seront déployés par snapin.

II - Cycle de vie des machines La « deuxième vie »

Cinq ans après Machine non garantie = machine hors production Après 5 ans de bons et loyaux services, les matériels sont renouvelés. Selon les matériels, leur degré d’obsolescence et la politique locale, plusieurs destinations sont possibles pour les matériels. Le matériel est encore d’une utilisation confortable : Le poste est destiné à un renfort des salles d’accès libre, reconditionné en kiosque ou, pour l’ « élite », conservation pour un remplacement ‘minute’. Le matériel est poussif ou obsolète (OS plus maintenu et prérequis non atteints) - Don aux associations. - Prise en charge par une société de recyclage labellisée. Titre du powerpoint Date – Prénom Nom de l’auteur

III - Assistance La prise en compte des demandes

Gestion des demandes Comme nous utilisons déjà un GLPI centralisé pour l’inventaire, nous l’utilisons aussi pour les demandes d’intervention (conjointement à son prédécesseur « esus- helpdesk »). Création de tickets par 4 voies : - Directement pas l’utilisateur - Par « moisson » d’un mail dédié - Par le call-desk - Par le technicien après coup Cet ordre est l’ordre préférentiel, qui n’est pas toujours celui qu’on constate ...

III - Assistance La gestion des demandes

Gestion des tickets Chaque créateur est propriétaire du ticket (après un éventuel transfert si c’est le technicien qui le crée) et est en charge d’approuver sa clôture après fermeture par le technicien. Si un ticket n’est pas pris en charge dans la demi journée, il est affecté à un technicien ou au correspondant du campus concerné par l’équipe de régulation. Si un ticket est clos sans approbation, il est fermé et le propriétaire est prévenu de cette clôture (il a la possibilité de ré-ouvrir la demande)

Gestion des escalades De par l’éclatement de notre université, nous avons adopté un fonctionnement par pôles. En effet, il est impossible (avec nos effectifs) de disposer d’équipes de spécialistes dans chaque antenne. En cas d’impossibilité de résolution par le technicien local, après diagnostic, le ticket est « escaladé ». - Directement par le gestionnaire de parc - Par l’équipe de supervision si le ticket a été clôturée par erreur et réouvert le demandeur.

Université de Lille www.univ-lille.fr