Installer un logiciel fourni sous forme de fichier tar.gz reste un passage obligé pour beaucoup d’admins et de développeurs Linux, surtout quand le paquet n’existe pas dans les dépôts de la distribution. Entre l’archive à extraire, les dépendances à installer, la phase de configure, le make qui compile puis le « make install » final, la moindre erreur de commande peut faire perdre du temps. L’idée ici est simple : repartir des bases, décortiquer chaque étape et montrer comment garder la main sur son système, sans transformer la machine en champ de mines de binaires bricolés.
Le scénario type sera celui d’un technicien qui récupère un outil réseau ou un petit démon système uniquement distribué en .tar.gz. On verra comment vérifier que le package n’existe pas déjà en .deb, .rpm ou via Flatpak/Snap, comment préparer l’environnement de compilation sur les principales distributions, puis comment extraire, configurer, compiler et installer le programme depuis le terminal. Au passage, quelques parallèles seront faits avec d’autres formats (comme dans le guide Installer un RPM sous Linux) pour replacer le tar.gz dans l’écosystème global. L’objectif est d’obtenir une méthode réutilisable sur n’importe quel serveur ou homelab, reproductible sans avoir besoin de recoller des bouts de documentation trouvés au hasard sur le web.
En bref
- Un fichier tar.gz est une archive tar compressée avec gzip, très utilisée pour distribuer des sources sous Linux.
- Avant d’installer depuis un .tar.gz, vérifier si le logiciel n’existe pas déjà en paquet de distribution ou via un format moderne (Snap, Flatpak, AppImage).
- L’installation typique suit le triptyque ./configure, make, sudo make install après extraction dans un répertoire de travail.
- Il faut souvent installer au préalable des dépendances et groupes « Development tools » pour que la compilation réussisse.
- Garder un œil sur l’emplacement d’installation et les fichiers générés facilite la mise à jour ou la désinstallation ultérieure.
Comprendre ce qu’est un fichier tar.gz sous Linux avant de l’installer
Avant d’ouvrir la moindre session en ligne de commande, il vaut mieux clarifier ce qu’on a réellement entre les mains. Un fichier .tar.gz n’est pas un « installateur magique » à la Windows, mais un combo de deux briques Unix historiques. D’un côté, tar assemble des fichiers dans une seule archive, sans compression. De l’autre, gzip compresse le résultat. Le fameux tar.gz, parfois écrit .tgz, n’est donc qu’un conteneur compressé, qui peut embarquer du code source, des scripts, de la documentation, ou même des binaires précompilés.
Ce point est souvent négligé par ceux qui arrivent de Windows et s’attendent à double-cliquer sur le fichier. Sur Linux, on ne parle pas de double-clic magique, même si les environnements graphiques savent extraire les archives par clic droit. L’étape décisive ne se joue pas là, mais dans ce qu’on fait du contenu décompressé. Selon les cas, on va lancer un binaire directement, exécuter un script « install.sh » ou passer par la séquence configure/make/make install. La logique ressemble plus à assembler un Lego technique qu’à lancer un setup.exe.
Autre point souvent confondu : tar et gz peuvent exister séparément. On peut tomber sur un .tar simple, donc non compressé, ou sur un .gz isolé qui n’est pas une archive, mais un fichier unique compressé. Le réflexe automatique « tar xzf » ne marchera pas toujours. D’ailleurs, pour les curieux qui veulent aller plus loin sur la compression, un détour par la commande gzip détaillée dans ce tutoriel gzip sous Linux donne un bon panorama des options utiles.
Dans le monde des distributions, les fichiers tar.gz sont très utilisés pour distribuer les sources officielles d’un logiciel, là où les .deb, .rpm ou paquets spécifiques sont souvent construits par les mainteneurs de distribution. En clair, passer par le tar.gz revient à se rapprocher de l’éditeur ou du développeur d’origine. C’est un avantage pour obtenir la toute dernière version, mais aussi un risque si l’on oublie la gestion centralisée des dépendances et des mises à jour que proposent apt, dnf ou pacman.
Un exemple concret : dans une petite PME, Julien télécharge un outil de supervision réseau fourni en .tar.gz parce qu’il a lu quelque part que la version packagée était « en retard ». Il compile directement sur son serveur de prod sans trop regarder. Six mois plus tard, une bibliothèque système est mise à jour via apt, l’outil ne démarre plus, et personne ne se souvient comment il a été installé. Sans méthode, le tar.gz peut vite devenir un caillou dans la chaussure. Comprendre la nature de ce format, c’est déjà anticiper ce genre de galère.
En résumé, un tar.gz est une boîte compacte qui peut contenir tout et n’importe quoi. La clé, ce n’est pas seulement de l’ouvrir, mais de comprendre la logique de ce qu’il y a derrière : sources, binaires, scripts et conventions. Le reste de l’article va justement détailler comment garder le contrôle à chaque étape.
Différence entre archive, compression et paquet installable
Beaucoup mélangent archive, compression et notion de paquet « installable ». Un fichier .tar ou .tar.gz reste une archive, point. Il n’embarque aucune logique de dépendances comme le fait un .deb ou un .rpm, aucune base interne d’installation, aucun système de désinstallation intégré. Quand on installe depuis une archive, on écrit souvent directement dans /usr/local, /opt ou /usr, et la distribution n’en sait strictement rien.
À l’inverse, un paquet natif géré par apt ou dnf suit une structure stricte, déclare ses dépendances, s’intègre aux outils de mise à jour et peut être retiré proprement. On le voit bien quand on passe d’un article sur les RPM à celui-ci. Un tour sur le guide installer des RPM sous Linux permet de comparer les approches : l’un parle de gestion centralisée, l’autre plutôt de bricolage maîtrisé.
Face à cette réalité, certains formats modernes comme Flatpak, Snap ou AppImage viennent combler le fossé. Ils promettent une installation plus isolée de l’OS, au prix d’une certaine lourdeur. Pourtant, pour un poste utilisateur classique, préférer un Flatpak à un tar.gz brut reste souvent une bonne idée. Le tar.gz garde toute sa pertinence en homelab, en environnement de test, ou pour installer un outil très spécifique sur un serveur technique.
La distinction n’est pas théorique. Elle change la manière de documenter ce qu’on fait. Sur un serveur critique, installer en production un logiciel uniquement disponible en tar.gz sans consigner les chemins d’installation ni les options de compilation est une mauvaise habitude. L’archive elle-même n’y est pour rien. C’est l’usage qu’on en fait qui rend les choses propres ou confuses.
L’idée générale est donc simple : voir le tar.gz comme une matière première à manipuler avec des outils Unix classiques, pas comme un équivalent de setup.exe ou d’un wizard graphique.
Préparer l’environnement Linux avant d’extraire et compiler un tar.gz
Une installation depuis sources qui se passe bien commence rarement par « tar xf ». La réalité, c’est qu’une bonne partie des erreurs viennent d’un système mal préparé : outils de développement absents, bibliothèques de base manquantes, droits root improvisés. Passer quelques minutes à préparer l’environnement évite des heures à décoder des logs d’erreur pendant le make.
Premier réflexe, vérifier la présence des outils minimaux. Sur Debian, Ubuntu ou Linux Mint, le trio de base ressemble à ceci depuis un terminal :
$ sudo apt update
$ sudo apt install tar gzip build-essential
Le paquet build-essential fédère gcc, make, les en-têtes indispensables et les utilitaires courants. Sur Fedora, CentOS, AlmaLinux ou RHEL, l’équivalent se fait via les groupes :
$ sudo dnf groups mark install « Development Tools »
$ sudo dnf groupinstall « Development Tools »
$ sudo dnf install tar gzip
Sur Arch ou Manjaro, le réflexe sera :
$ sudo pacman -Sy base-devel tar gzip
Certains jugeront ces groupes trop larges pour un simple test. En réalité, sur un poste de développement ou un serveur de lab, installer ces métapaquets une fois pour toutes simplifie vraiment la vie. Vouloir n’installer que gcc et make au cas par cas finit souvent en collection de bibliothèques manquantes, surtout avec des projets C ou C++ un peu conséquents.
Autre point de préparation rarement évoqué : l’organisation des répertoires de build. Travailler directement dans /tmp ou dans le home root rend les choses vite illisibles. Une approche plus propre consiste à réserver un dossier comme ~/build ou ~/sources, dans lequel chaque projet aura son propre sous-répertoire. Quand il faudra revenir corriger une compilation six mois plus tard, retrouver le contexte sera beaucoup plus simple.
Enfin, même si le sujet sort un peu du strict tar.gz, garder un système rangé côté stockage reste pertinent. Les captures Wireshark, dumps tcpdump et archives successives peuvent saturer un disque sans prévenir. Le cas d’un disque quasi plein est courant, aussi sous Linux que sous Windows. Le guide sur le fameux dossier qui n’a plus de place sous Windows illustre le même type de dérive côté poste utilisateur : accumuler des fichiers sans politique claire finit toujours par bloquer un projet au mauvais moment.
Gérer les dépendances avant la compilation du tar.gz
Les outils généraux ne suffisent pas. Chaque projet distribué en .tar.gz arrive avec ses propres dépendances. Bibliothèques SSL, modules graphiques, bibliothèques de base de données… C’est ici que la documentation incluse dans l’archive prend tout son sens. Dans la plupart des cas, un fichier README, INSTALL ou même un fichier texte dans un sous-répertoire « docs » liste les prérequis à installer par le gestionnaire de paquets.
Ignorer ces fichiers et lancer « ./configure && make » en espérant que tout passe relève de la roulette russe. Les erreurs du script configure sont souvent très explicites : « library X not found », « header Y missing ». L’astuce consiste à installer la variante « -dev » ou « -devel » de la bibliothèque mentionnée. Par exemple, une erreur sur OpenSSL se résout souvent avec un apt install libssl-dev ou un dnf install openssl-devel. Pour ceux qui jonglent aussi avec du Windows, le parallèle avec le tuto installer OpenSSL sous Windows est parlant : même technologie, contraintes très différentes selon l’OS.
Pour rester cohérent, il vaut mieux noter quelque part les paquets installés pour faire fonctionner un projet précis. Dans une PME où plusieurs admins se relaient, un simple fichier texte dans /root ou dans un repo Git interne vaut largement mieux qu’un souvenir approximatif. Celui qui reprendra le serveur plus tard remerciera celui qui a documenté les apt install et dnf install nécessaires.
Cette phase de préparation peut paraître fastidieuse sur le moment, mais elle conditionne la stabilité de la compilation. En clair, un tar.gz se manie beaucoup mieux sur une base technique propre que sur un système bricolé au fil des années.
Extraire un fichier tar.gz sous Linux: commandes pratiques et cas d’usage
Une fois l’environnement prêt, vient enfin le moment de l’extraction. C’est souvent la première commande qu’on tape, et paradoxalement celle qu’on maîtrise le moins. Pourtant, comprendre ce que fait réellement « tar » évite quelques surprises, comme un répertoire décompressé au mauvais endroit ou un écrasement discret de fichiers existants.
La forme la plus classique pour extraire une archive tar.gz reste :
$ tar xzf nom_du_programme.tar.gz
La combinaison « xzf » signifie : extraire, décompresser avec z (gzip) et afficher les noms de fichiers (f pour indiquer qu’on travaille sur un fichier, pas sur une bande magnétique comme à l’époque). Beaucoup de documentation ajoute la lettre « v » pour mode verbeux :
$ tar xvzf nom_du_programme.tar.gz
Cette variante liste les fichiers en cours de décompression. Utile pour voir rapidement la structure du projet sans se plonger immédiatement dans le répertoire généré.
Pour un .tar.bz2, la logique est identique, seule l’option de décompression change :
$ tar xjf nom_du_programme.tar.bz2
ou avec verbeux
$ tar xvjf nom_du_programme.tar.bz2
Le point de vigilance, c’est le répertoire courant. La commande tar extrait dans le dossier où l’on se trouve. Par habitude, il vaut mieux se positionner d’abord dans le répertoire de build choisi, par exemple :
$ cd ~/build
$ tar xzf ~/Téléchargements/nom_du_programme.tar.gz
On garde ainsi tous les projets au même endroit, et on évite de semer des répertoires « program-1.0 » dans /root ou /var au hasard de ses tests.
Extraction graphique et ponts avec d’autres systèmes
Tout le monde ne vit pas dans un tty plein écran. Sur les postes de bureau, la plupart des environnements graphiques (GNOME, KDE, XFCE) savent ouvrir un tar.gz par un simple clic droit « Extraire ici » ou « Extraire vers… ». Pour tester rapidement le contenu d’une archive, cette approche fonctionne très bien. On peut ensuite ouvrir un terminal dans le répertoire décompressé pour enchainer avec la compilation.
Côté utilisateurs qui alternent souvent entre Linux et Windows, la question revient régulièrement : comment ouvrir un tar.gz sur Windows pour jeter un œil au code ou à la doc ? Des outils comme 7-Zip ou WinZip gèrent ce format sans problème. On ouvre l’archive, on sélectionne les fichiers voulus, on clique sur extraire, exactement comme avec un zip classique. Cette capacité se révèle utile quand on gère un environnement mixte avec des développeurs sous Windows et de la prod sous Linux, comme dans certains contextes VMware décrits dans l’article sur les différences entre ESX et ESXi.
Enfin, pour les curieux qui manipulent aussi des formats plus exotiques, on retrouve régulièrement des tar.gz dans des distributions atypiques ou anciennes, comme celles évoquées dans l’article sur Meego Linux. Dans ces cas-là, l’extraction reste exactement la même, même si le reste de la chaîne d’outils a pu évoluer.
Une fois l’archive correctement extraite, il reste à entrer dans le répertoire de travail :
$ cd nom_du_programme
C’est à partir de là que démarre réellement la phase de compilation, avec son lot de scripts configure et de makefiles. L’extraction n’est qu’une étape, mais si elle est faite proprement, tout le reste sera plus lisible.
Configurer, compiler et installer un tar.gz: la séquence configure / make / make install
C’est souvent ici que la différence entre utilisateur avancé et bricoleur occasionnel se voit. Beaucoup connaissent la suite de commandes par cœur, sans forcément savoir ce qui se passe à chaque étape. Pourtant, comprendre le rôle de configure, de make et de « make install » permet d’adapter la procédure, de débuguer plus vite et de mieux intégrer le logiciel au système.
Une fois dans le répertoire extrait, la première chose à regarder est la présence de fichiers clés : configure, CMakeLists.txt, setup.py, ou même un script install.sh. Chaque projet choisit son outil de build. Le cas le plus courant en C/C++ reste le traditionnel script configure :
$ ./configure
Ce script sonde le système, vérifie la présence des bibliothèques, détermine les chemins d’installation et génère un ou plusieurs Makefile adaptés à l’environnement. On peut souvent lui passer des options pour changer des répertoires ou activer/désactiver des fonctionnalités. Par exemple :
$ ./configure –prefix=/usr/local –disable-static
Le paramètre –prefix décide du répertoire racine dans lequel le logiciel sera installé. Utiliser /usr/local plutôt que /usr reste une bonne habitude, car cela sépare ce qui vient de la distribution de ce qui a été ajouté à la main depuis un tar.gz ou un autre canal.
Une fois configure terminé sans erreur, vient la phase de compilation :
$ make
La commande lit le Makefile et construit les binaires. Sur une machine multi-cœurs, on peut gagner du temps en parallélisant la compilation :
$ make -j4 pour utiliser 4 jobs en parallèle, par exemple.
Si tout se passe bien, aucun message d’erreur ne s’affiche, ou seulement quelques warnings. En cas d’erreur, remonter un peu dans la sortie du terminal pour repérer la première trace d’échec, souvent liée à une bibliothèque absente ou à une incompatibilité de version.
Enfin, une fois la compilation terminée, vient l’installation proprement dite :
$ sudo make install
Cette étape copie les binaires, bibliothèques et fichiers de configuration aux emplacements définis par le configure précédent. Elle requiert des droits administrateur, car elle écrit généralement dans /usr/local/bin, /usr/local/lib, /etc, etc. À ce stade, le système considère le programme comme installé, même si le gestionnaire de paquets ne le connaît pas.
Résumé des commandes essentielles pour installer un tar.gz
Pour garder une vision claire de la chaîne complète, voici un tableau récapitulatif des commandes les plus fréquentes et de leur rôle. Il ne remplace pas la documentation du projet, mais sert de mémo pour la démarche générale.
| Étape | Commande type | Rôle principal |
|---|---|---|
| Téléchargement | $ wget URL_du_tar.gz ou navigateur | Récupérer l’archive sur la machine Linux |
| Extraction | $ tar xzf programme.tar.gz | Décompresser l’archive dans le répertoire courant |
| Navigation | $ cd programme-1.0 | Entrer dans le dossier de sources décompressé |
| Configuration | $ ./configure –prefix=/usr/local | Générer les Makefiles adaptés au système |
| Compilation | $ make -j4 | Construire les binaires à partir des sources |
| Installation | $ sudo make install | Copier les fichiers aux emplacements d’exécution |
Bien sûr, certains projets n’utilisent ni configure ni make classique. On croise parfois des scripts Python (setup.py install), des systèmes basés sur CMake (cmake puis make), ou des scripts shell sur mesure. Dans tous les cas, la logique reste proche : préparer, bâtir, déployer. C’est là que la lecture d’un README bien fait fait gagner beaucoup de temps.
À cette étape, on entre clairement dans le domaine des admins et devs qui aiment garder la main sur ce qui tourne sur leurs serveurs. Ce n’est pas une coïncidence si on retrouve souvent ces approches dans les labs de test Proxmox, ESXi et autres environnements hybrides, comme on le voit sur les montages décrits dans l’article installer Proxmox sur VMware. Sur ces plateformes, savoir compiler et installer proprement un outil spécialisé depuis un tar.gz est clairement un plus.
Gérer les problèmes courants lors de l’installation d’un tar.gz: erreurs, sécurité et maintenance
Aucun tuto sérieux sur l’installation de tar.gz ne peut éviter le sujet des problèmes récurrents. Entre les erreurs de compilation, les conflits de versions de bibliothèques et les mauvaises surprises de sécurité, la réalité en production n’a rien à voir avec un cas d’école parfait. Autant aborder ces points frontalement.
Première catégorie d’ennuis : les erreurs de configure ou make. Un classique, le fameux « No such file or directory » pour un header ou « undefined reference to » pour une fonction lors de l’édition de liens. Dans 80 % des cas, la racine du problème est une bibliothèque de développement manquante. Installer la version -dev ou -devel du paquet cité dans le message puis relancer configure et faire un make clean/make règle souvent l’affaire.
Deuxième catégorie : les soucis de droits ou de chemins d’installation. Lancer « make install » avec un prefix qui pointe vers /usr sans y faire attention peut écraser une version de bibliothèque gérée par le système. Dans les pires cas, cela peut casser d’autres applications. D’où l’intérêt de cibler /usr/local, voire un répertoire dédié comme /opt/monlogiciel, histoire de compartimenter un peu le bazar.
Troisième famille, la sécurité. Installer un logiciel depuis un .tar.gz trouvé au hasard sur un forum, sans signature ni checksum, revient à faire entrer un inconnu dans la salle serveurs en lui tendant les clés. Sur un serveur exposé, copier un démon réseau ou un agent quelconque sans vérifier sa provenance ressemble furieusement aux erreurs déjà vues sur d’autres technologies. Ceux qui ont géré des incidents autour de mauvaises pratiques sécurité dans des environnements VMware, du type décrits dans l’article erreurs de sécurité VMware, savent ce que cela peut impliquer.
Enfin, la maintenance pose une vraie question : comment mettre à jour proprement un logiciel installé par « sudo make install » alors que le gestionnaire de paquets n’en sait rien ? La réponse la plus saine reste souvent de repasser par la même procédure avec une nouvelle version de l’archive, dans le même préfixe, après un make uninstall quand le projet le propose. Dans les cas plus complexes, recourir à des outils comme checkinstall ou construire ses propres paquets .deb/.rpm peut être une stratégie plus industrialisable.
Surveillance, logs et intégration dans un système vivant
Une fois installé, le programme issu du tar.gz n’est pas figé dans le marbre. Il vit, il log, il plante parfois. L’intégrer dans les outils habituels de surveillance du système est souvent oublié. Utiliser des commandes comme tail ou tailf sur les fichiers de logs, comme détaillé dans le tuto surveiller avec tailf sous Linux, aide beaucoup à suivre un démon fraîchement compilé. On garde ainsi un œil sur ses comportements, ses erreurs et ses pics d’activité.
Dans les environnements où Linux cohabite étroitement avec Windows, cette approche « instrumentée » rejoint d’autres réflexes, comme analyser le trafic réseau avec tcpdump côté Linux et un équivalent sur Windows, sujet évoqué dans le guide tcpdump et capture réseau sous Windows. Le logiciel issu du tar.gz n’échappe pas à ces bonnes pratiques : log, monitoring, documentation.
Un dernier point à ne pas sous-estimer concerne la réversibilité. Installer un logiciel critique depuis un tar.gz, sans script de désinstallation, dans un environnement de production très normé, peut être vu comme un anti-pattern par certaines équipes de sécurité ou de conformité. Dans ces cas-là, mieux vaut passer un peu plus de temps à construire un paquet natif ou à utiliser un format containerisé plutôt que d’improviser une installation brute, même si le tar.gz rend la chose très tentante.
Au final, gérer proprement les problèmes autour des archives tar.gz, c’est surtout accepter que chaque commande tapée en root laisse une trace. Plus ces traces sont documentées, surveillées et réversibles, moins l’installation depuis sources ressemble à une expérience risquée.
Comment savoir si je dois utiliser un tar.gz ou un paquet de ma distribution ?
Par défaut, mieux vaut installer un logiciel via le gestionnaire de paquets de la distribution (apt, dnf, pacman) ou un format moderne comme Snap/Flatpak. Le fichier tar.gz devient intéressant si la version packagée est trop ancienne, si le logiciel n’existe pas dans les dépôts ou si vous devez activer des options de compilation spécifiques. Sur un serveur critique, privilégiez les paquets natifs dès que c’est possible pour faciliter les mises à jour et la désinstallation.
Quelles sont les commandes minimales pour installer un tar.gz classique ?
Dans le cas standard avec un script configure, la séquence type est la suivante : 1) tar xzf logiciel.tar.gz, 2) cd logiciel-1.0, 3) ./configure –prefix=/usr/local, 4) make -j4, 5) sudo make install. Selon le projet, certaines étapes peuvent varier (CMake, setup.py, script install.sh), mais l’idée reste de préparer, compiler puis copier les fichiers au bon endroit. Toujours vérifier les fichiers README ou INSTALL fournis par l’éditeur avant de se lancer.
Comment désinstaller un logiciel installé via make install ?
Certains projets proposent une cible make uninstall, qu’il suffit d’exécuter depuis le même répertoire de build, avec les mêmes options de configure qu’à l’installation. Si ce n’est pas le cas, la désinstallation peut devenir manuelle (suppression des binaires, bibliothèques et fichiers de configuration) ou passer par la reconstruction d’un paquet .deb/.rpm avec des outils comme checkinstall. Pour les logiciels critiques, éviter les installations sans chemin clair de désinstallation.
Puis-je installer plusieurs versions d’un même logiciel depuis des tar.gz différents ?
C’est possible en jouant sur l’option –prefix du script configure, par exemple en installant une version dans /opt/logiciel-v1 et une autre dans /opt/logiciel-v2. Cette approche demande de gérer les chemins (PATH, LD_LIBRARY_PATH) avec soin pour lancer la bonne version au bon moment. Pour de la simple production, cumuler plusieurs versions n’est pas recommandé, mais pour des tests ou un homelab, cela peut rendre service.
Que faire si le script configure échoue à cause d’une dépendance manquante ?
Lire attentivement le message d’erreur et identifier le nom de la bibliothèque ou du fichier d’en-tête absent. Ensuite, installer la variante de développement correspondante via le gestionnaire de paquets : par exemple libssl-dev sur Debian/Ubuntu ou openssl-devel sur Fedora pour une dépendance SSL. Une fois les paquets installés, relancer ./configure puis make. Si les erreurs persistent, vérifier la documentation fournie dans l’archive pour voir si une version précise de la bibliothèque est requise.
