Déployer des postes techniques sous Linux en entreprise

Demandé depuis plusieurs années par les équipes techniques chez Groupe CREATIVE, il y a eu quelques étapes à respecter avant de pouvoir déployer des postes sous linux en entreprise.

Les sources utilisées dans cet article sont disponibles sur Github:

https://github.com/groupe-creative/linux-desktop-autoinstall

Le contexte

Comme dans de nombreuses sociétés, Groupe CREATIVE a articulé la gestion de son parc informatique (et en particulier la partie "Desktop") autour de solutions Microsoft (Active Directory, Serveur DNS, Sytème de GPO, etc).

On se retrouve avec un écosystème fonctionnel, simple à mettre en place, totalement centralisé dans sa gestion des utilisateurs, dans le déploiement de logiciels sur postes distants, etc.

Mais Windows a également ses limites, en particulier dans le monde du Dev... On notera (entre autre):

• Une consommation de Ram excessive
• Une liste de problèmes sans fin lorsqu'on utilise Docker (performance, crash, config à revoir régulièrement, etc.)
• Un peu d'espoir avec avec l'arrivée de WSL mais pas toujours trivial à installer / configurer ...
• Des outils conçus pour linux avec des versions Windows pas toujours performantes
• Du code réalisé / testé sous Windows avec de Frameworks / Middlewares Windows alors qu'en production tout doit fonctionner sous Linux...
• Etc. (ce n'est pas le sujet de cet article)

Les contraintes du SI

Avant de pouvoir déployer une flotte de PC sous Linux en entreprise, certaines contraintes étaient à respecter (liste non exhaustive):

• Etre capable d'ajouter les postes Linux dans l'Active Directory du groupe
• Etre capable pour les utilisateurs de se connecter au poste Linux avec leur compte AD
• Etre capable de se connecter au réseau (filaire et wifi) depuis nos locaux protégés via 802.1x, ainsi qu'à distance via VPN.
• Etre capable d'accéder aux points de montage réseau du groupe (Samba) avec les droits de l'utilisateur connecté sur le poste
• Etre capable d'obtenir un minimum d'info sur les postes à distance
• Etre capable de forcer le déploiement d'outils (et de code) à distance (au même titre que le système de GPO existant)
• Etre capable de gérer une flotte de PC hétérogènes (avec les contraintes matériels pouvant exister sous Linux)
• Quid du pack Office ?
• Quid de l'antivirus (dont la gestion et le déploiement est centralisé) ?
• ...
• Et peut être la plus importante, être capable d'automatiser l'installation et la configuration des futurs postes sous linux pour ne pas y passer des heures et pouvoir s'assurer que tous les postes soient adaptés au SI du groupe.

Let's GO

La première étapes a bien évidement été de valider la faisabilité technique, de montrer qu'on était capable de répondre à toutes les contraintes de notre SI à partir d'un poste "pilote".

Bien que certains points ont été un peu plus compliqués que d'autres à traiter, chaque problème à trouver sa solution.

La suite de cet article a pour objectif de présenter comment on s'y est prit pour automatiser l'installation de nos postes sous Linux (tout en répondant à nos contraintes d'infrastructure).

Le choix du système d'exploitation

Il y a plusieurs écoles... Du puriste à l'utilisateur occasionnel... On a tranché pour du "commun"...

On a choisit Ubuntu Desktop comme distribution cible, dernière version stable en date (21.10 actuellement, 22.04 dans quelques semaines) sans s'imposer du LTS.

Ubuntu dispose d'une solide communauté, est fortement répandu sur notre parc de serveurs, propose des mises à jour très régulièrement, fait de gros efforts pour s'intégrer de plus en plus facilement dans le monde de l'entreprise, etc. C'est donc un excellent candidat.

Le mode de déploiement

Impossible d'utiliser notre service MDT pour déployer du Linux... Fort dommage mais du coup on va reprendre l'idée et faire du déploiement via PXE.

Vaste sujet lorsque l'on commence à s'y intéresser... La documentation est minimaliste, souvent un peu ancienne, pas facile de savoir pour où commencer...

Ce qu'il faut retenir, c'est que déployer linux via PXE, cela nécessite:

• Un VLAN dédié (si vous avez déjà un service du même type déjà en place pour déployer Windows)
• Quelques prises réseaux reliés à ce VLAN pour pouvoir démarrer les postes sur le service PXE
• Déployer les composants qui vont constituer notre service de boot via le réseau (DHCP, TFTP, PXE, Serveur Web, etc).

Sans citer toutes les solutions étudiées, celle qui a été retenue (en particulier pour sa simplicité), a été d'utiliser "FOG"

Une fois la partie infrastructure en place, il suffit d'y déployer une VM et d'y installer FOG (les tutoriels sont nombreux sur le net). FOG se charge d'instancier pour vous tous les composants dont vous pourriez avoir besoin (et même plus... peut-être même trop pour ce qu'on va en faire ici).

FOG est pensé pour réaliser des modèles d'images à partir de machines sur le  réseau, restaurer ces images sur des machines, gérer un parc informatique, déployer des paquets à distance, etc. Mais nous n'utiliserons aucune de ces fonctionnalités ici.

Il ne semble pas concevable de réaliser des images linux pour chaque type de PC de notre parc informatique, encore moins de devoir refaire des images à chaque nouveau modèle, chaque nouvelle version d'Ubuntu.

La solution la plus flexible à notre sens, lancer l'installation via le réseau d'un ISO officiel avec une installation sans intervention humaine.

L'installation automatisée d'Ubuntu Desktop

Là encore, on retrouve tout un tas d'informations sur internet, très disparates et souvent très anciennes, pas simple de s'y retrouver.

La méthode utilisée ici a été testée sur "Ubuntu 21.10" et sur "Ubuntu 22.04".

Si vous souhaitez installer une distribution Ubuntu récente et que vous tomber dans vos recherches sur la notion de "preseed file", vous êtes au mauvais endroit, il s'agit d'un ancien système d'automatisation Debian.

Sur les dernières versions d'Ubuntu, un nouveau mécanisme d'installation automatique a été mis en place (documentation officielle).

A noter que ce mécanisme n'est valable que pour "Ubuntu Server" (et non "Ubuntu Desktop qui nous intéresse ici). La bonne nouvelle c'est qu'Ubuntu Desktop, ce n'est finalement qu'une version "Server" avec le package "ubuntu-desktop" en plus.

Pour automatiser l'installation (et ne pas avoir à saisir des informations lors de la phase d'installation du Système d'exploitation), vous aurez besoin de vous créer un fichier "user-data" qui correspond à vos besoins.

Vous trouverez le fichier user-data que nous avons utilisé ici.

Dans les grandes lignes, c'est grâce à ce fichier que l'on peut:

• Choisir la langue du clavier ainsi que la local à utiliser
• Définir la configuration réseau par défaut (dans notre cas, ne connaissant pas le nom exacte de l'interface réseau, on recherche toutes les cartes réseaux de type "eth*" et "en*", on les configure en DHCP et on spécifie un serveur DNS en complément)
• Définir le partitionnement des disques (dans notre cas, on recherche le plus gros SSD sur la machine qu'on va formater entièrement pour y installer notre système d'exploitation)
• Préciser un nom par défaut pour la machine (qui sera modifié dans l'étape suivante) ainsi que définir le compte utilisateur "administrateur" de la machine.
• Installer des packages supplémentaires (ici, uniquement "ubuntu-desktop")
• Exécuter quelques actions complémentaires (dans notre exemple, on se contente de télécharger un script "finish-install-setup.sh" qui sera placé sur le bureau de l'utilisateur créé par défaut (l'administrateur))
• On termine l'installation avec une mise à jour du système

Une fois ce fichier "user-data" préparé, il reste:

• A rendre accessible ce fichier au moment du boot PXE
• Télécharger (et rendre disponible) un ISO Ubuntu Server
• Extraire de l'ISO (et rendre accessible) la partie "casper" (qui contient la section inirt / iniramfs utile pour charger en RAM un "mini" système d'exploitation au moment du boot)
• Créer une entrée de menu FOG pour booter sur notre ISO

Pour plus d'information sur ces dernières étapes, vous pouvez vous référer à la documentation sur Github : https://github.com/groupe-creative/linux-desktop-autoinstall/tree/main/pxe

Terminer la configuration

Lorsque l'installation est terminée, le PC redémarre, vous arrivez sur une page d'authentification, il suffit de se connecter avec l'utilisateur "ubuntu/ubuntu".

Si tout s'est bien passé, vous trouvez sur votre bureau un petit script "finish-install-setup.sh".

Ce script se contente d'installer Ansible, de télécharger un playbook, puis de le lancer pour terminer la configuration.

Il ne reste plus qu'à lancer ce script pour:

• Renseigner le nom du PC

Ce script va se charger du rester:

• Enregistrer le PC dans l'Active Directory du groupe
• Configurer l'authentification utilisateur avec l'AD
• Installer les logiciels de bases qui vous sont utiles (Mattermost, Teams, TeamViewer, etc)
• Installer les éléments liés à l'infrastructure (certificats, contraintes réseaux, sécurité, etc)
• Déposer un petit Guide sur le bureau des utilisateurs qui seront amenés à utiliser ce poste
• Faire un peu de ménage.

Pour plus d'information sur le playbook utilisé, vous pouvez vous référer à la documentation sur Github : https://github.com/groupe-creative/linux-desktop-autoinstall/tree/main/ansible-playbook

Ce qui n'est pas automatisé

Non présent dans le repo Github, un petit guide est déposé sur le bureau Ubuntu de chaque utilisateur. Ce guide contient les quelques étapes qui n'ont pu être automatisées.

Le 802.1X

L'authentification 802.1X permet de sécuriser l'accès à un réseau interne.

Ce système peut être configuré de différentes manières, dans notre cas il repose en partie sur les identifiants de l'utilisateur.

A défaut d'avoir trouvé une solution pour utiliser les informations d'identification de session, nous avons laissé cette étape à la charge de l'utilisateur final. Il lui suffit d'ouvrir les paramètres réseaux, d'aller dans l'onglet "Sécurité" et d'y renseigner les paramètres mentionnés dans le Guide Utilisateur.

Le procédé est identique pour l'accès au réseau Wifi ou via VPN.

Le Client Mail

Cette étape pourrait probablement être automatisée à condition de trouver le client mail qui vous convient. Resterai à chaque de l'utilisateur de renseigner ces identifiants au lancement du client mail.

Une solution de contournement consiste à utiliser la capacité de Google Chrome à transformer une page Web et Webapp Native. On se connecter à notre compte Office 365, on ouvre Outlook, puis au niveau de Chrome

... > Plus d'outils > Créer un raccourci... > Cocher "Ouvrir dans une fenêtre" > OK

On se retrouve avec un raccourci sur le bureau que l'on peut ajouter à côté des autres applications dans la barre de menu, et qui ouvre Outlook comme une application native.

Le Pack Office

Concernant Microsoft Office, pas de magie mais plusieurs solutions possibles.

Côté Technique ce n'est pas l'outil le plus utilisé, pour du dépannage et consulter des documents:

• Utiliser Open Office installé par défaut
• Utiliser Office 365 en mode web (ou Webapp)

En cas de besoin d'un vrai pack Office, une solution acceptable (pour nous) consiste à déployer sur le poste une VM Windows 10/11 (via VirtualBox).

Cette VM est initialisé avec les identifiants AD de l'utilisateur (il se retrouve avec les mêmes droits / composants que s'il s'agissait d'un poste sous Windows), il peut y installer un vrai pack Microsoft Office, partager ses répertoires entre la VM et son poste pour accéder rapidement à tous ses documents.

Tips VM Windows

Il est possible que le poste utilisé soit livré avec une licence Windows de type OEM. Si c'est le cas, il est possible de réutiliser cette licence pour votre VM.

# Pour vérifier la présence d'un licence OEM sur votre poste
sudo tail -c +56 /sys/firmware/acpi/tables/MSDM

# Ajout de la table MSDM à la configuration de la VM
sudo cat /sys/firmware/acpi/tables/MSDM > ~/VirtualBox_VMs/Windows11/msdm.bin
VBoxManage setextradata Windows11 "VBoxInternal/Devices/acpi/0/Config/CustomTable" ~/VirtualBox_VMs/Windows11/msdm.bin

L'accès aux points de montage Réseau

Rien de très compliqué ici, mais toujours à la charge de l'utilisateur car il devra renseigner ses identifiants AD.

Il lui suffit d'ajouter un emplacement réseau du type

smb://mon_serveur_de_fichiers

Après saisie des identifiants, libre à l'utilisateur d'ajouter quelques raccourcis dans ses favoris.

L'antivirus

Pour des raisons de sécurité, l'antivirus utilisé par Groupe CREATIVE ne sera pas cité ici.

Si votre Antivirus d'entreprise n'est pas compatible avec Ubuntu, vous pouvez vous orienter vers ClamAV.

Gestion des GPO

Différentes solutions existent pour simuler le système de GPO proposé par Windows.

A défaut d'avoir eu le temps de tester les différents outils sur le marché (FOG semble un bon candidat), chacun ayant ses contraintes, nous avons développé notre propre système (très lite) qui nous suffira dans un premier temps.

Il s'agit d'un Repository Git (téléchargeable et installable lors de l'étape de finalisation de la configuration) qui va installer différents services systèmes.

Source Github : https://github.com/groupe-creative/linux-gpo

Basé sur un système de playbook Ansible, les différents services installés se charge de puller régulièrement de repository et d'exécuter le playbook pour y déployer de manière décentralisée du code et/ou des applications.

Les limitations rencontrées

Problème de drivers

Nous avons rencontrés quelques problèmes avec les drivers de cartes réseaux sur des PC récents (ainsi que sur les dongles USB/RJ45)  lors du boot PXE d'Ubuntu 21.10. L'absence de drivers réseaux rend forcément compliqué l'installation d'un OS via PXE. Ce problème était lié à l'absence de ce drivers dans le mini système d'exploitation qui est chargé en RAM (initrd / initramfs) avant de charger l'ISO pour l'installation. Ce problème a été résolu dans la version d'Ubuntu 22.04

Jouer avec le BIOS

Installer Ubuntu peut vite devenir contraignant si vous imposez du "Secure Boot" ou activez certaines options de sécurité au niveau du BIOS. Tout est faisable, à vous de trouver le juste milieu.

PXE en HTTPS

Au moment du Boot PXE on se retrouve nativement un système d'exploitation qui n'aura pas connaissance de votre autorité de certification (ce qui va poser problème si votre service PXE utilise des certificats générer par une autorité de certifications interne).

Deux possibilités:

• Tunner la partie "boot" pour y incorporer votre CA (opération potentiellement complexe)
• Oublier le HTTPS, vos PC démarrent en PXE sur un VLAN dédié, isolé, avec aucune information réellement à sécuriser lors de l'installation de l'OS. Une fois l'OS installé, plus de soucis, pour peut terminer la configuration en HTTPS.