💾 Archived View for lord.re › drafts › retour-suite-cours › index.gmi captured on 2022-06-03 at 23:37:55. Gemini links have been rewritten to link to archived content
➡️ Next capture (2024-08-18)
-=-=-=-=-=-=-
-------------------------------------------------
[01/01/0001] - ~7mins -
-------------------------------------------------
Bon c'est un ptit article de vrac.
Chaque année je dispense quelques cours de Licence Pro ASUR (Administration et Sécurisation des Réseau) où j'interviens juste ponctuellement deux fois dans l'année.
Je ne connais pas spécialement le programme (en dehors de ce que je donne) mais c'est très orienté Linux et logiciels libres.
Mon cours est … très court.
Par contre la très grande majorité est en fait un TP qui aborde pas mal de points différents dans le domaine en question.
Je pense qu'assommer les pauvres étudiants n'est clairement pas la bonne façon de faire et qu'il faut les balancer à la flotte au plus tôt pour qu'ils cherchent et appréhendent d'eux-mêmes le truc.
Et du coup, je lâche très vite les élèves avec tout un tas de questions qui sont un peu orientées mais pas trop, d'abord assez limitées dans leur scope puis de plus en plus ouvertes.
Et force est de constater, qu'ils n'ont pas l'habitude de rédiger autre chose que des réponses bêtes et méchantes.
Ils peuvent pondre des screenshots, même quelques schémas, copier/coller les commandes.
Mais argumenter leur réponse, justifier leur raisonnement ou juste expliquer très succintement leur raisonnement bha là ils savent pas faire.
J'ai beau mettre un préambule assez massif où j'indique qu'une réponse techniquement fausse mais avec le bon raisonnement sera comptée comme juste, que les screenshots du résultat de leur commande je m'en bas les steaks s'il n'y a pas d'explication avec mais … non.
Et même si je le rabâche toute la journée (quand je tourne dans la salle pour leur filer un coup de main/les orienter/donner des indices/expliquer des notions) que je n'ai pas besoin qu'ils me prouvent qu'ils ont réussi à faire ce que je demandais mais qu'ils me prouvent qu'ils ont compris ce qu'ils ont fait… bha non, ils restent scolaires.
Bon du coup pour éviter de faire un blogpost rien que pour râler, je vais dans la suite donner quelques pistes pour améliorer les compte-rendu et aussi quelques tips divers et variés (on sait jamais, s'ils tombent sur ce blog ça pourrait les aider).
- *Lire les questions complètement et si ce n'est pas clair demander des compléments d'informations.*
Ça peut paraître con mais quand on vous demande de nommer le fichier que vous allez rendre d'une certaine façon, pour pas passer pour un tâcheron avant même que votre compte-rendu soit lu c'est de respecter ça.
Et quand on vous dit de multiples fois et qu'on vous Ă©crit que les captures d'Ă©cran n'ont aucune valeur, pas la peine de perdre du temps Ă en faire.
Quand votre TP c'est 90% de commandes shell, au mieux vous n'avez qu'à faire du copié/collé de votre terminal.
- *Quand on vous dit de vous méfier des tutos sur le web et de privilégier le man, c'est qu'il y a une raison.*
Ça fait dix ans que je prodigue les mêmes cours/TP et dix ans que je tombe sur des réponses choppées sur les mêmes tutos sur le net avec les mêmes conneries obsolètes depuis des lustres.
Les intervenants extérieurs ne sont pas là pour vous faire chier, au contraire, on arrive avec un état d'esprit clairement positif à votre égard.
Souvent on a fait les mêmes études/diplômes et tout ce qu'on souhaite, c'est partager notre savoir/passion en faisant en sorte que vous ayez l'impression d'avoir progressé.
On n'est pas là pour le pognon mais clairement dans une démarche positive et pour vous directement et plus globalement pour la profession (meilleur sont les étudiants, meilleurs seront les gens dans leur taff plus tard).
Si vous faites un Bac+3 pour contenter papa et maman mais que vous ĂŞtes en souffrance, vous serez en souffrance toute votre vie.
Arrêtez les frais au plus vite et réorientez-vous au plus vite.
- *Si on vous dit que tel truc est déprécié/obsolète, demandez pourquoi ? par quoi on remplace ?*
Demandez pas "Pourquoi on m'a enseigné ça ?", ça fait pas avancer le débat et si alors que vous êtes encore étudiant vous refusez de remettre en question le peu de savoir que vous avez, qu'est-ce que ce sera dans cinq ans/dix ans …
L'informatique est un milieu qui évolue constamment et pour pas être largué vous allez vous aussi devoir évoluer avec.
Donc si "ifconfig est déprécié depuis 18 ans" votre réaction devrait pas être "ouai mais je comprend rien à ip" mais "bon jvais me sortir les doigts, oublier le peu que je connais d'ifconfig et me mettre sérieusement à ip".
Vous n'avez pas encore des habitudes fortement encrées, c'est maintenant qu'il faut réapprendre et pas après dix ans de mauvaises habitudes solidement impreignez dans votre cerveau.
N'abordez pas votre apprentissage par de la méfiance (encore une fois, si je vous le dit c'est pas pour vous faire chier, c'est pour que vous soyez plus à l'aise, plus performant, plus à jour).
Si vous êtes en apprentissage avec des vieux briscards adminsys, ne pompez pas leur défaut mais soyez prêt à leur apporter un nouveau savoir à eux aussi.
Le *man* est la documentation à peu près officielle.
Certaines pages sont effectivement assez rébarbative mais globalement c'est quand même assez bien foutu (surtout dans le cas de ssh).
Mais il faut apprendre Ă s'en servir.
Ça utilise des raccourcis assez commun sous Linux.
Par exemple, pour chercher vous pouvez utiliser *<kbd>/</kbd>* puis vous tapez le mot que vous cherchez.
Ensuite avec *<kbd>n</kbd>* vous irez à la prochaine occurence du mot recherché.
C'est tout con mais rien que le fait de connaître ça rend le truc utilisable.
Tous les man ont un ordre assez similaire : d'abord le nom de la commande, ensuite le synopsis qui donne un résumé bref, ensuite la description qui va indiquer toutes les options possibles avec leur intéret, ensuite des précisions en fonction du programme (dans le cas de ssh ça explique le fonctionnement de l'authentification, les caractères d'échappements, le tunneling, la gestion des clés d'hôte, bref des trucs spécifique qui apportent pas mal de complément d'information), ensuite le voir aussi qui cite d'autres pages man en rapport pour compléter et enfin les auteurs.
Il y a parfois une section exemple qui regroupe les utilisations communes des logiciels ce qui peut vous faire gagner pas mal de temps, pensez-y, le man c'est pas un tuto mais c'est bien mieux une fois outrepassé la laideur du bousin.
Le synopsis c'est pas mal mais si vous comprenez pas sa syntaxe c'est balot ça aide pas trop.
Prenons l'exemple du man ssh
<kbd>ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command]</kbd>
Bon déjà , tout ce qui est entouré de crochet est facultatif.
Donc dans notre exemple le minimal obligatoire est <kbd>ssh destination</kbd>.
Et quand on regarde un peu plus bas dans le man ils indiquennt Ă propos de destination : may be specified as either [user@]hostname or a URI of the form ssh://[user@]hostname[:port]. avec la mĂŞme syntaxe des crochets.
Revenons à l'exemple, ua début il y a le gros pâté <kbd>[-46AaCfGgKkMNnqsTtVvXxYy]</kbd> qui indique toutes les options qui n'ont pas besoin d'argument et que vous pouvez donc tout collé à la suite, mais c'est pas obligatoire, vous pouvez faire <kbd>-4 -A -f</kbd> ou bien <kbd>-4Af</kbd>.
VoilĂ
C'est con de devoir le dire, mais les messages d'erreurs sont pas fait pour être ignorés.
Les logiciels biens faits ont des messages d'erreurs qui veulent dire quelque chose et assez explicite.
Et quand c'est pas le cas, il faut parfois rajouter un *<kbd>-v</kbd>* pour activer le mode verbeux qui détaille un peu plus ce que fait le programme ce qui peut être précieux.
------------
Bon même si j'ai l'air assez énervé et aggressif en vrai pas tant que ça.
Cette année j'ai été très agréablement surpris, contraiment aux deux/trois années précédentes le niveau était bien meilleur mais surtout le sérieux global était très largement en amélioration.
J'avais une appréhension suite à l'année précédente qui était assez catastrophique mais ils m'ont redonné l'envie de continuer.
C'était agréable pour moi et j'ai eu l'impression que ça l'était aussi pour eux.
------------------------------------
------------------------------------
[01/01/0001] <no value>
------------------------------------