Semestre 1
Ces matières m'ont apporté les bases théoriques et pratiques indispensables pour comprendre l'interaction entre un système d'exploitation et le matériel, ainsi que pour installer un environnement de travail propre. En R1.04 (Introduction aux systèmes d'exploitation), j'ai appris le fonctionnement des systèmes multi-utilisateurs, la gestion des droits (sudo), les commandes de base du terminal et l'usage des gestionnaires de paquets comme APT. La ressource R1.03 (Architecture des ordinateurs) m'a permis de mieux comprendre la gestion des composants matériels (CPU, RAM, stockage), ce qui s'est avéré crucial lorsqu'il a fallu allouer intelligemment les ressources de ma machine hôte à une machine virtuelle. Enfin, R1.10 (Anglais) a été indispensable pour comprendre les interfaces d'installation d'Ubuntu, configurer Rufus et déchiffrer la documentation technique en ligne.
1. Démarches, prises de décisions, implication et autonomie
Pour cette SAÉ, l'objectif était de préparer et de configurer un poste de travail Linux (Ubuntu 24.04 LTS) adapté aux besoins d'un développeur à l'IUT, en explorant et en comparant trois approches : WSL, le Dual Boot et la virtualisation avec VirtualBox.
Notre première étape a consisté à étudier chaque solution afin d'en comprendre les forces et les limites. Nous avons commencé par la méthode la plus rapide : WSL1 sous Windows. L'installation s'est faite via le Microsoft Store, et j'ai choisi spécifiquement la version 24.04 LTS afin de bénéficier d'un support stable sur 5 ans et de paquets récents. Pour tester l'environnement, nous avons créé une petite arborescence de répertoires en ligne de commande (mkdir, cd), puis nous avons validé le fonctionnement graphique en installant l'éditeur Geany et le package ninvaders.
Pour la partie Dual Boot, la démarche était plus délicate, car elle touchait directement au matériel. Nous avons dû prendre des décisions de sécurité importantes : sauvegarder nos données sur une clé externe par précaution, désactiver le chiffrement Windows BitLocker qui bloquait le partitionnement, et utiliser l'outil Rufus pour flasher l'ISO d'Ubuntu. Nous avons choisi d'allouer une partition d'environ 100 Go afin d'être à l'aise.
Enfin, pour VirtualBox, nous avons configuré une machine virtuelle en mode "accès par pont" (Bridged), après avoir hésité avec le mode NAT. Nous avons retenu le mode pont pour que la VM dispose de sa propre adresse IP sur le réseau local, ce qui la rend plus accessible depuis l'extérieur.
En termes d'autonomie, nous avons avancé seuls dans la configuration des environnements, en nous appuyant sur la documentation d'Ubuntu-fr. Ma principale implication a été de m'assurer que toutes les dépendances de l'IUT (compilateurs, outils Git, bases de données) étaient correctement installées et fonctionnelles.
2. Ressources choisies et combinées
Nous avons combiné plusieurs enseignements pour mener à bien ce projet :
• R1.04 (Systèmes d'exploitation) & R1.03 (Architecture) : Pour la machine virtuelle, ces deux ressources ont été déterminantes pour choisir l'allocation des ressources. Nous avons attribué 12 Go de RAM et 3 cœurs de CPU à la VM, tout en laissant au moins 4 Go à Windows afin d'éviter que l'hôte ne plante. Les concepts de R1.04 se sont concrétisés lors de la création de l'utilisateur ("pizza") et de l'utilisation intensive des privilèges sudo pour mettre à jour APT (sudo apt update && sudo apt upgrade).
• R1.04 & Outils de développement : Pour installer l'environnement de l'IUT en une seule fois, nous avons mobilisé nos connaissances de la commande apt install pour y intégrer un ensemble conséquent de dépendances : des outils de versioning (git, subversion), des outils de build Java (maven, gradle), des éditeurs (geany, vscode) et des SGBD (sqlite3).
• R1.11 (Bases de la communication) & R1.10 (Anglais) : Ces ressources ont été utiles pour la rédaction des livrables (le dossier d'étude, la notice d'utilisation) et pour la configuration des OS, souvent paramétrés par défaut en anglais lors de la phase d'installation (choix de la timezone, disposition du clavier).
3. Justification de la maîtrise des apprentissages critiques
• AC13.01 | Identifier les différents composants (matériels et logiciels) d’un système numérique Justification : Notre rapport montre que nous avons bien identifié les composants d’un poste. Nous avons su distinguer l’interaction CPU directe de WSL1 de l’usage d’un hyperviseur de type 2 (VirtualBox), qui s’appuie sur l’OS hôte pour gérer la RAM et le stockage. De plus, le fait d’avoir identifié la nécessité de désactiver BitLocker afin d’installer le bootloader GRUB confirme notre compréhension des composants logiciels de bas niveau au démarrage de la machine.
• AC13.02 | Utiliser les fonctionnalités de base d’un système multitâches / multiutilisateurs Justification : Les captures d’écran de nos terminaux attestent de cette maîtrise. Nous manipulons l’arborescence Linux de manière fluide (pwd, ls, cd), nous gérons la création de dossiers pour plusieurs utilisateurs simulés (user1, user2) et nous utilisons correctement la commande sudo pour exécuter des tâches administratives avec les privilèges root.
• AC13.03 | Installer et configurer un système d’exploitation et des outils de développement Justification : Nous avons mené à bien trois installations distinctes d’Ubuntu 24.04. Le poste de développement est pleinement opérationnel, car la commande globale d’installation des dépendances a permis de déployer avec succès tout l’écosystème Java (JDK, javac, JVM), ainsi que les outils indispensables demandés par le client (IUT).
4. Ressources manquantes / Si c'était à refaire
Même si toutes nos installations ont fonctionné, il nous a manqué des bases en scripting Shell (Bash). Pour installer toutes les dépendances de l'IUT, nous avons copié-collé une très longue commande sudo apt install regroupant plus de 20 paquets. Si c'était à refaire, j'écrirais un véritable script Bash automatisé (un fichier .sh) avec des conditions pour vérifier si les paquets sont déjà installés, ce qui aurait été plus professionnel et plus propre pour le client.
Ensuite, concernant WSL, nous avons utilisé la version 1. Avec le recul, il nous manquait une meilleure compréhension de WSL2 et de son fonctionnement, qui repose sur un noyau Linux complet embarqué dans une VM légère. Nous aurions dû configurer la plateforme virtuelle de Windows pour passer sous WSL2 afin de bénéficier de meilleures performances sur le système de fichiers.
Enfin, pour le Dual Boot, la modification du BIOS et l'ajustement manuel de l'ordre de boot (via les touches F2 / F10) se sont faits un peu à tâtons selon les machines. Une ressource ou un TP dédié à la configuration des firmwares (UEFI/BIOS) et à la table de partitionnement GPT/MBR en amont nous aurait évité quelques moments de stress lors du redémarrage de l'ordinateur.