Devenir SysAdmin d’une PME - Gestion du legacy- Billet n°1
22 mai 2018 09:00 4 messagesTAGS : Sysadmin Planet Libre Tutoriaux Devenir SysAdmin d’une PME
Ce billet fait partie de la série :
– Devenir SysAdmin d’une PME, retour d’expérience - Billet n°0
Le legacy ?
Dans le présent billet je voudrais parler du legacy. Sous le terme de legacy ou héritage en anglais, j’inclue l’ensemble des machines et serveurs du système d’information que l’on a en gestion, et dont, on hérite d’une certaine façon en reprenant la gestion du parc informatique.
En quoi est-ce un point important ? Afin de pouvoir aller vers l’avenir, il faut déjà regarder le passé et faire un état des lieux. L’objectif est d’avoir une parfaite vue d’ensemble des machines, de leurs rôles, de leurs criticités... De savoir ce qui est documenté et ce qui ne l’est pas, de savoir quelle machine sert à quoi...
En premier lieu il est important de dresser un inventaire exhaustif du par informatique côté serveur (dans un premier temps on exclue les postes utilisateurs : chacun est administrateur de sa machine, sous une distribution GNU/Linux de son choix et cela simplifie grandement les choses en terme de maintenance des postes utilisateurs...)
Dresser une cartographie complète de l’existant
A ma connaissance, il y a deux façons : la façon barbare et la façon longue et fastidieuse
La façon barbare : Il faut préalable connaître l’ensemble des plages IP utilisées sur le réseau de l’entreprise et on fait alors un scan en mode intense via Nmap de l’ensemble des IP de ces plages, depuis une machine du réseau interne. Avec un peu de chance on se fait bannir rapidement par un outil de détection... ou pas.
Ce scan intense permet de savoir sur quelle IP quelle machine répond, d’avoir son OS et sa version, les ports ouverts... A moins que les machines soient bien configurées et sécurisées, cela donne une bonne idée des plages IP occupées, des machines qu’il y a derrière et donne une bonne base de travail.
La façon plus moderne
Avec un peu de chance un outil du type Ansible a été mis en place et les machines sont ansiblelisées. On pourra donc se baser (se reposer) sur des playbooks existants pour avoir une base pour interroger les machines de façon moins barbare.
la façon longue et fastidieuse
J’évoquais dans mon article précédent le fait que je ne pars pas de rien, j’ai connaissance d’une liste des machines, dont des hyperviseurs sur lesquels tournent des machines virtuelles. J’ai accès à ces hyperviseurs. Je me connecte donc au hyperviseurs et de là je me connecte aux machines virtuelles. Je notes les caractéristiques qui m’intéressent, je vois ce que ces machines contiennent en terme de services... Une à une, je me connecte à la machine et je note les informations pertinentes dans un tableau que j’enrichis au fur et à mesure.
Long. Très long. Mais cela m’a permis de valider que j’ai bien accès à chacune des machines (j’ai ensuite tester une connexion depuis ma machine en SSH pour valider que ma clef publique a bien été déployée sur chaque serveur par le système qui le fait de façon automatisée), que la machine est accessible, fonctionnelle...
Tableau de suivi
J’ai donc constitué un tableau dans un tableur pour faire mon suivi. Les colonnes sont les suivantes :
– Nom de machine,
– IP publique
– IP privée
– Groupe
– Wiki : j’ai créer une page dédiée pour cette machine que j’enrichis au fur et à mesure
– Services
– Etat des sauvegardes : sauvegardée ou non
– Version de l’OS
– Etat des mises à jour
– Présence ou non de fail2ban
– Liste des ports ouverts sur l’extérieur
– Machine faisant partie de la liste des machines supervisées par notre outil (un billet complet sera dédié à la supervision).
...
Comment gérer le legacy ? Des O.S. obsolètes...
Que ce soit des machines virtuelles ou physiques, le constat est bien ce que l’on pouvait redouter : des tas de machines sont souvent sous des versions obsolètes d’O.S. non maintenues... Il va y avoir du travail.
Il ne faut surtout pas se précipiter et migrer de version en version de Debian à coup de dist-upgrade. Il faut comprendre pourquoi ces machines ne sont pas à jour, quels logiciels et dans quels versions tournent sur ces serveurs... Dépendance à une version particulière de PHP ? La migration sur une version plus récente casse une API ? Les raisons sont multiples et avant de penser "Et la sécurité, vite faut mettre à jour", il faut penser "de toute façon ça tournait jusque là, donc on reste calme, on réfléchit et on avise".
Il faut prendre ça avec humour.
Vu les uptime et les versions d’OS, vu que le parc informatique est composé à 99% de machine Debian en version stable (de différentes époques), je peux affirmer que oui, Debian stable, c’est stable.
Comment gérer le legacy ? Cas de la gestion des machines physiques
Dans la liste des serveurs, il y a des machines qui sont des vrais serveurs physiques. On pense donc aux capacités de redondance : alimentations redondées, ventilateurs redondés, disques en RAID... Le soucis est que je ne sais pas quand les machines ont été achetés, elles tournent 24h sur 24h...
Dans une vie précédente, j’ai été confronté au cas suivant : des serveurs de plus de dix ans... Un ventilateur de la baie de disque a lâché. Pas grave, c’est redondé, on verra bien. Sauf que le deuxième ventilateur a tourné plus vite pour compenser la dissipation de chaleur nécessaire, a lâché quelques jours après. Interruption de la baie de disques et de la production, nécessité de renouveler du matériel en urgence et bien que sous garantie étendue par le constructeur, ils ont mis plusieurs jours à retrouver un modèle compatible au fin d’un stock à l’autre bout de la France et à le faire revenir... en urgence...
Cette expérience m’a marquée et depuis, je fais un check régulier des machines de la salle serveur. Un contrôle journalier des différents voyants des différents serveurs. L’objectif est de prévoir & anticiper les pannes.
Et surtout je commence à anticiper et à prévoir une migration de toutes les machines que je peux migrer sur des machines virtuelles avec des O.S. plus récent et ansiblelisés. L’intérêt de passer de machines physiques à des machines virtuelles dans un vraie data-center et de faire abstraction de la gestion du matériel et de délégué ça à des personnes dont c’est vraiment le métier...
Comment gérer le legacy ? Lister les priorités et les services critiques
Une fois que l’on a une cartographie un peu plus complète, il faut alors lister les machines critiques, avec leurs importances (serveur de mail, d’impression, DNS...) et au plus vite vérifier :
– que l’on a des sauvegardes et que l’on sait les restaurer ;
– que ces sauvegardes marchent ;
– que les machines sont à jour...
Il faut savoir pour chaque machine sa criticité, avoir un PRA (Plan de Rétablissement de l’Activité) et pour le cas des sauvegardes, partir du principe que si on ne sait pas, cela n’existe pas. Peut-être (et sûrement) qu’il y a des sauvegardes régulières et automatisées. Mais si on ne sait pas, on ne sait donc pas restaurer les données et les sauvegardes ne servent à rien en l’état. Donc là encore un gros chantier pour vérifier que tout est bien sauvegarder et avoir un système de sauvegarde uniforme, efficace et puissant (BORG !).
Conclusion
Un deuxième billet qui montre le début d’un long chantier que j’ai entamé avec plusieurs heures de travail par jour pendant des semaines.
Dans les prochains sujets, il y aura la Supervision, les Sauvegardes, la Sécurité, les montées en version et les mises à jours.... Encore plein de sujets et d’expériences à faire sur mon histoire et comment je deviens SysAdmin d’une PME. A suivre donc.
Dans la même rubrique
17 décembre 2019 – Usage du preseed pour faciliter l’installation de ses serveurs Debian
18 septembre 2019 – Devenir SysAdmin d’une PME - Quelques outils et scanners de vulnérabilités
13 septembre 2019 – Devenir SysAdmin d’une PME - Reprise des billets
14 novembre 2018 – Devenir SysAdmin d’une PME - De l’importance de l’expérience
12 novembre 2018 – Devenir SysAdmin d’une PME - De l’importance du retex suite à un incident
4 Messages
Inventaire, paulez | 22 mai 2018 - 20:24 1
Salut ! Si tu veux utiliser quelque chose de plus évolutif qu’un tableau je te conseille de regarder du côté des solutions d’inventaire. Un avantage de ce type de solution est que l’inventaire peut-être automatisé et donc être maintenu à jour sans effort. J’ai utilisé Glpi dans ma jeunesse et c’est pas mal.
Tu peux par exemple déployer un agent avec Ansible qui fera remonter régulièrement des infos sur tes machines physiques ou virtuelles dans la base de donnée d’inventaire.
Devenir SysAdmin d’une PME - Gestion du legacy- Billet n°1, Buzut | 23 mai 2018 - 01:47 2
Hello,
Billet très intéressant. J’ai noté une petite type : que tout est bien sauvegard[er]é.
Tchô !
Devenir SysAdmin d’une PME - Gestion du legacy- Billet n°1, Jonathan | 23 mai 2018 - 11:06 3
Merci pour votre retour sur votre nouveau travail. C’est vraiment passionnant !
Ça donne des idées, permet de se remettre en question sur certains points et d’apprendre bien entendu ^^
J’utilise aussi Debian de mon côté sur mon petit serveur maison (perso/pro) pour différents services dont web, dns dhcp, musique et logiciel pro... Tout ça avec des conteneurs lxc. Et c’est vraiment sympa !
Je ne sais pas si c’est envisageable dans votre infra (lxc, lxd), mais voilà une autre piste de réflexion.
Merci encore !
Jo
Devenir SysAdmin d’une PME - Gestion du legacy- Billet n°1, xhark | 23 mai 2018 - 17:16 4
Si tu as du VMware alors je te conseille chaudement RVTools (freeware) qui va inventorier tout ça pour toi !