CLI Linux et permissions : survivre dans un monde sans souris

« La modification est terminée ! » …mais pour le déploiement ?

Trois mois après mon arrivée dans l’entreprise, alors que ma période d’essai touchait à sa fin, j’ai reçu pour la première fois une vraie tâche de production. Ce n’était qu’une toute petite correction fonctionnelle, mais j’étais quand même à la fois nerveux et excité en terminant la modification du code et les tests sur ma propre machine, sur localhost.

« Chef, tous les tests locaux sont passés ! »

Mon responsable a hoché la tête et m’a dit de déployer. « Bon travail. Maintenant, faites un commit sur GitLab, un dépôt de code comme GitHub, puis déployez sur le serveur de production. »

Déployer ? J’ai fouillé en vitesse dans le document de passation que j’avais reçu à mon arrivée. Il était rempli de termes inconnus.

J’ai d’abord envoyé le code comme on me l’avait demandé. Il ne restait plus que la dernière étape : se connecter au serveur de production. J’ai même commencé à me lever de ma chaise. Comme dans les séries, je croyais qu’il fallait entrer dans une salle serveur glaciale, un IDC, et taper directement sur un clavier branché au serveur.

Mon senior m’a vu et s’est mis à rire. « Vous allez où ? Restez assis et connectez-vous simplement en SSH. »

Ma première rencontre avec l’écran noir

J’ai ouvert un programme appelé SSH(Secure Shell), saisi l’adresse IP et le mot de passe donnés par mon senior, puis appuyé sur Entrée. Si cela avait été Windows, un bureau coloré m’aurait accueilli. Mais sur mon écran, il n’y avait qu’un curseur clignotant sur fond noir.

ubuntu@ip-172-31-0-1:~$ _

Il n’y avait aucune icône à cliquer avec la souris, ni de menu clic droit pour créer un nouveau dossier. Pris de panique, j’ai appuyé sur n’importe quelle touche, puis j’ai tapé ls, et une liste de fichiers est apparue en texte brut.

« Ah, donc c’est ça, cette CLI(Command Line Interface) dont j’avais seulement entendu parler. »

Mais la vraie peur est arrivée quand j’ai voulu exécuter un fichier. J’ai lancé le script update mentionné dans le manuel, et ce qui aurait été un simple double-clic sous Windows s’est transformé ici en message d’erreur rouge.

Permission denied (permission refusée)

C’était mon propre serveur, et pourtant je ne pouvais pas exécuter le script. Pourquoi Linux était-il si peu accueillant ?

Le gardien d’entrepôt d’un centre logistique numérique

Revenons à notre métaphore du ‘centre logistique numérique’. Si mon portable sous Windows est un bureau personnel confortable, alors un serveur Linux est un immense entrepôt construit uniquement pour traiter de la logistique. Dans cet entrepôt s’empilent des dizaines de milliers de boîtes, c’est-à-dire des fichiers.

Si le gardien devait se déplacer à pied pour inspecter chaque boîte une par une, GUI, et ouvrir chaque porte avec une clé, clic après clic, le travail serait bien trop lent. C’est pour cela que Linux utilise un talkie-walkie appelé commandes.

« Affichez la liste complète des boîtes de la zone 1 ! » (ls) « Déplacez la boîte 3 vers la zone 5 ! » (mv) « Exécutez cette boîte ! » (./start.sh)

Ce n’est pas inconfortable parce qu’il n’y a pas de souris. Les graphismes ont été supprimés volontairement parce qu’une fois habitué, on peut contrôler des milliers de fichiers cent fois plus vite qu’avec une souris.

[Code Verification] La loi absolue des permissions

Ce qui fait le plus souffrir les débutants sous Linux, c’est justement la question des permissions. Sous Windows, un clic sur ‘Exécuter en tant qu’administrateur’ règle presque tout. Linux, lui, vérifie strictement pour chaque fichier qui peut faire quoi.

Pour survivre, il faut savoir lire cette langue extraterrestre qui apparaît avec ls -l dans le terminal.

$ ls -l myscript.sh
-rwxr-xr--  1  owner  group  1024  Jan 1 12:00  myscript.sh

Analyse : la partie essentielle, c’est -rwxr-xr-- tout au début. En excluant le premier -, qui indique un fichier, il faut le lire par groupes de trois.

Un script que vous avez écrit ne s’exécute pas ? Neuf fois sur dix, c’est parce qu’il manque le droit d’exécution, x. C’est à ce moment-là que les débutants, frustrés, lancent le sort interdit chmod 777.

# Ce qu il ne faut jamais faire
$ chmod 777 myscript.sh

777 signifie : « Moi, toi et même le chien qui passe pouvons modifier et exécuter ce fichier. » C’est l’équivalent d’ouvrir en grand votre portail de sécurité. En pratique, c’est absolument interdit. Il faut prendre l’habitude d’accorder uniquement les permissions minimales nécessaires, comme chmod +x.

Conseil pratique : surmonter la peur du terminal

Quand je suis entré dans l’entreprise, mon senior m’a dit d’utiliser PuTTY comme outil de connexion au serveur. Mais en cherchant sur Internet, j’ai trouvé un meilleur outil, MobaXterm. Dès qu’on se connecte en SSH, ce programme affiche sur la gauche une liste de fichiers en SFTP, presque comme l’explorateur de fichiers de mon propre ordinateur.

Grâce à ça, même sans vraiment connaître les commandes du terminal, je pouvais double-cliquer sur des fichiers pour les modifier et les enregistrer. Mais si l’on ne s’appuie que sur ce genre d’astuce, on ne devient jamais vraiment à l’aise avec Linux. En cas d’incident urgent, vous n’avez pas le temps d’attendre qu’un outil graphique se lance.

Conclusion : celui qui maîtrise l’environnement

Quitter la serre appelée Windows pour s’adapter à la nature sauvage appelée Linux est douloureux. Mais une fois cette douleur dépassée, on obtient un niveau de contrôle qu’aucune souris ne pourra jamais offrir.

Linux n’est plus un territoire inconnu. Mais un problème fondamental demeure. Et si Java 17 était installé sur mon portable, donc dans l’environnement de développement, alors que le serveur Linux, donc l’environnement de déploiement, n’avait que Java 8 ? Ou si une bibliothèque existait sous Linux mais pas sur mon Windows ?

L’excuse « Chez moi, ça marche » vient des différences de système d’exploitation et de versions de bibliothèques. N’y aurait-il pas un moyen d’éliminer totalement cet écart d’environnement ? Ne pourrait-on pas figer l’environnement de mon portable tel quel et l’emporter sur le serveur ?

Il existe une technologie qui a transformé cette idée apparemment absurde en réalité. La prochaine fois, parlons de Docker, la technologie qui a dépassé la virtualisation et lancé la révolution des conteneurs.