RS - Réseaux et Systèmes



L'objectif de ce module est d'apprendre à devenir un utilisateur avancé du système et maîtriser la programmation système. Il ne s'agit pas de comprendre comment le système fonctionne (ce qui constitue l'objectif du module de RSA), mais plutôt comment tirer le maximum du système.

Evaluation:

1 Projet RS 2017/2018 - tesh

1.1 2017-10-22 le sujet

1.2 2017-10-26 Informations à inclure dans vos questions

Quand vous m’envoyez des questions, pensez à inclure: - un lien vers votre projet sur GitLab - un lien vers le fichier qui pose problème (si c’est utile) - toute autre information utile

Je me réserve le droit de répondre plus lentement aux demandes qui n’incluent pas les informations nécessaires.

1.3 2017-10-26 Accès à GitLab pour les étudiants des Mines

Pour se connecter à GitLab, il faut utiliser votre adresse Prenom.Nom@telecomnancy.eu (même si vous n’êtes pas étudiant à TELECOM Nancy).

1.4 2017-10-26 GitLab et erreurs de compilation

Q: Les builds automatiques sur GitLab retournent une erreur. C’est grave ?

R: Ces builds automatiques sont là pour vous aider à détecter des problèmes dans vos projets. Le script lancé est visible ici, et ne fait rien de sorcier. En théorie, il ne devrait pas retourner d’erreurs. S’il échoue, c’est soit:

A noter que certains tests sont effectués mais ne retournent pas d’erreur pour l’instant (par exemple, celui qui vérifie le bon fonctionnement du shell dans un cas basique). Ils seront modifiés plus tard.

Le fait de ne pas passer ces tests ne sera pas directement pénalisant pour l’évaluation. Par contre, le fait de rendre un projet qui nécessitera des adaptations pour être compilé sera pénalisant, évidemment. Donc il vaut mieux faire l’effort de passer les tests GitLab.

1.5 2017-10-27 Format des scripts Tesh

Q: quel est le format des scripts tesh que le shell doit pouvoir exécuter en mode non-interactif ?

R: c’est simplement une série de commandes, telles qu’elles seraient tapées au clavier. Par exemple, ce qui suit est un script tesh valide:

echo a
true && echo b
false || echo c ; echo d

Vous pourriez être tentés d’écrire un vrai parser pour traiter les lignes de commande tesh. C’est une possibilité, mais en pratique, pous pouvez probablement vous contenter d’un parsing basique (l’énoncé restreint la syntaxe de manière à ce que cela reste abordable).

1.6 2017-10-27 sortir de tesh

Q: comment l’utilisateur doit-il indiquer qu’il souhaite sortir de tesh ?

R: il n’est pas demandé d’implémenter un built-in “exit”. Vous pouvez vous contenter d’attendre (et de tester) la fin du fichier (EOF). En mode interactif, pour indiquer la fin de fichier, vous pouvez utiliser CTRL+D (c’est d’ailleurs aussi le moyen le plus rapide pour fermer un terminal, ou se déconnecter d’une connexion SSH).

1.7 2017-10-27 initiatives personnelles, bonus, etc.

Q: les initiatives personnelles seront-elles valorisées par des points bonus ?

R: tout d’abord, je rappelle que l’évaluation se fera en grande partie par des tests automatiques de votre code. Il est donc important d’implémenter ce qui est demandé dans le sujet sans en dévier. En particulier, évitez les modifications cosmétiques qui changeraient la sortie ou le comportement du shell, car elles pourraient faire échouer votre programme lors des tests automatiques.

Quand des groupes auront suffisamment avancé dans le projet, j’essaierai de vous donner quelques idées d’extensions (qui seront valorisées, même si la note maximale reste 20).

1.8 2017-10-29 Localisation de libreadline.so

Q: où se trouvera libreadline.so dans l’environnement de test ?

R: c’est la version du système (paquet Debian) qui sera installée, et qu’il faudra utiliser. Donc, il faut laisser dlopen() le trouver tout seul. Il ne faut surtout pas committer dans votre git une version que vous auriez compilée vous-même: rien ne dit que l’architecture de l’environnement de test correspondra à celle de votre machine.

1.9 2017-11-03 Enchainement de &&, ||, ; sur la même ligne

Q: comment le shell doit-il se comporter dans ce cas ?

R: comme un shell POSIX. Vous pouvez comparer le comportement de votre programme avec bash, par exemple.

1.10 2017-11-03 Puis-je appeler un shell (sh, bash, etc.) depuis tesh ?

R: L’objectif du projet est d’implémenter un shell. Il est donc logiquement interdit de s’appuyer sur l’exécution d’un autre shell pour réaliser votre implémentation. Sinon, votre projet pourrait presque se résumer à un system(“bash”) ;)

1.11 2017-11-06 Résultats des premiers tests blancs

Les résultats des premiers tests blancs sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-11-06/VOTREPROJET.html. Par exemple, si le nom de votre projet est “rs2017-dupont-dupond”, alors vos résultats sont https://members.loria.fr/lnussbaum/RS2017/2017-11-06/rs2017-dupont-dupond.html.

Ces tests ne sont pas notés (seul les tests finaux seront utilisés pour vous évaluer). Donc, si vous ne réussissez pas les tests pour l’instant, ce n’est grave : utilisez les résultats pour améliorer votre programme et passer les tests la prochaine fois.

Les trois derniers points du sujet (lancement de commandes en arrière plan ; édition de la ligne de commande ; chargement dynamique de readline) ne sont pas encore couverts par des tests.

Pour détecter des erreurs d’utilisation de la mémoire (accès à une zone mémoire non allouée par exemple), ElectricFence est utilisé (voir sa page de manuel et un article d’introduction). Pour l’utiliser, il suffit de précharger la bibliothèque avec export LD_PRELOAD=libefence.so.0.0 puis de lancer le programme normalement. ElectricFence fera crasher le programme s’il y a des erreurs, et vous pouvez utiliser gdb pour comprendre pourquoi.

Si votre projet n’apparait pas dans les résultats, c’est probablement que vous l’avez mal créé. Vérifiez avec la page permettant de vérifier la configuration des projets sur Gitlab.

Vous pensez avoir trouvé un bug dans les tests ? C’est possible ; contactez moi.

Erratum: j’ai mis à jour les résultats des tests vers 15h pour régler un problème avec ElectricFence, qui considérait de manière un peu trop agressive les allocations de 0 octets comme des erreurs. Merci à Jérémy Thivet pour avoir remonté le problème.

1.12 2017-11-13 Comment les tests sont-ils lancés ?

R: Pour les premiers tests (ceux sans TTY), tesh est lancé, les commandes à exécuter sont envoyées sur son entrée standard, puis l’entrée standard est fermée. Vous devriez pouvoir reproduire le même comportement avec, par exemple :

echo 'echo foo' | ./tesh

ou

echo -e 'echo foo\necho bar' | ./tesh

(D’ailleurs, c’est aussi ainsi que le comportement de votre shell est testé par gitlab, à chaque ‘git push’.)

De votre côté, ça veut dire qu’il faut tester la fin de fichier, et s’arrêter dans ce cas (voir la question “sortir de tesh” plus haut).

1.13 2017-11-14 Processus en arrière plan

Q: En dehors de leur lancement et de leur attente, faut-il faire quelque chose de particulier concernant les processus lancés en arrière plan ?

R: Non, ils s’exécutent normalement (et peuvent accéder directement au terminal pour y écrire leur sortie).

1.14 2017-11-19 Résultats des tests blancs

Les résultats des tests blancs sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-11-19/VOTREPROJET.html.

1.15 2017-11-20 Extension facultative (points bonus)

Comme vous l’avez probablement remarqué, la syntaxe proposée par le sujet est définie de manière à être assez facile à analyser “à la main”. Pour faire le lien avec le module de TRAD, vous pourriez tenter d’utiliser à la place lex/yacc (ou plutôt flex/bison), et être plus tolérant (par exemple, analyser correctement

true&&echo foo

ou même

true&&echo "foo bar" baz>fichier   # dans ce cas, argv[1] = "foo bar", argv[2] = "baz"

Cette extension, outre mon admiration, vous rapportera des points bonus : il sera possible d’avoir 20/20 sans faire cette partie, mais cette partie pourra permettre de compenser des problèmes par ailleurs.

1.16 2017-11-21 Comment doit fonctionner l’exécution en arrière plan ?

Prenons cet exemple :

true &
sleep 1
echo bar
fg

On commence par exécuter la commander “true” en arrière plan, ce qui génère la sortie:

[42]

(si 42 est le PID du processus fils). Puis, le shell exécute “sleep 1”, puis “echo bar” (ce qui affiche “bar”), puis “fg”. C’est au moment où on exécute “fg” que le shell va attendre (si besoin) le processus fils, et afficher son code de retour:

[42->0]

La seule sortie possible est donc:

[42]
bar
[42->0]

J’insiste: la phrase:

Dans tous les cas, le shell doit afficher le PID du processus en arrière plan qui a terminé, et son code de retour, sous la forme [pid->retcode] (par exemple [42->2], si le processus 42 a terminé avec le code de retour 2.

concerne ce qui se passe lors de l’exécution de la commande “fg”. “Dans tous les cas” fait référence aux deux cas expliqués précédemment (fg avec ou sans paramètre).

1.17 2017-11-22 J’ai bien implémenté “cd”, mais ça n’a aucun effet sur mon terminal …

L’appel système chdir() ne change le répertoire de travail que pour le processus courant (et les processus fils qui seront créés après le changement de répertoire). Il n’a pas d’effet sur le processus parent. Dans votre cas, le processus parent (le shell bash dans votre terminal) lance un processus fils (votre shell tesh), qui fait un chdir(). Seul le répertoire courant de tesh est modifié, pas celui de bash.

C’est d’ailleurs pour ça qu’il faut implémenter “cd” comme un built-in. Si c’était une commande externe, alors elle n’aurait d’effet que sur elle-même.

1.18 2017-11-28 Je ne comprends pas la sortie du premier test (Test basic) ou de celui lancé à chaque commit sur gitlab

Dans les deux cas, ‘echo foo’ est envoyé sur l’entrée standard de tesh, comme avec:

echo 'echo foo' | ./tesh

La sortie de ce test doit être:

foo

Et c’est tout !

Concrètement:

1.19 2017-12-01 Résultats des tests blancs

Les résultats des tests blancs sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-01/VOTREPROJET.html.

Prochains tests aux alentours du 12/12/2017.

1.20 2017-12-04 Nouveaux tests blancs avec un nouveau test: basic_no_efence

Vous êtes plusieurs à remonter des “Segmentation fault” inexpliqués. Comme dit dans un commentaire précédent : pour détecter des erreurs d’utilisation de la mémoire (accès à une zone mémoire non allouée par exemple), ElectricFence est utilisé (voir sa page de manuel et un article d’introduction). Pour l’utiliser, il suffit de précharger la bibliothèque avec export LD_PRELOAD=libefence.so.0.0 puis de lancer le programme normalement. ElectricFence fera crasher le programme s’il y a des erreurs, et vous pouvez utiliser gdb pour comprendre pourquoi (avant d’utiliser gdb, pensez à recompiler votre programme avec l’option ‘-g’ de gcc, pour inclure les informations de debug).

Pour vous aider à identifier les crashs dûs à des problèmes de mémoire, j’ai ajouté un test “basic_no_efence” pour lequel ElectricFence est désactivé. Si votre programme réussit ce test, mais pas “basic”, alors c’est probablement que vous gérez mal la mémoire.

Les résultats des nouveaux tests sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-04/VOTREPROJET.html.

1.21 2017-12-05 Un peu de lecture

Un peu de lecture en lien avec le projet:

Update 07/12: Il y a d’ailleurs eu un exposé sur LD_PRELOAD dans le club de hacking de TELECOM Nancy

1.22 2017-12-07 Dans les tests ‘bg’, le PID est affiché en retard

Une cause possible (et pas évidente) pour cela est:

(si vous testez vous-même, vous pouvez reproduire le problème avec “./tesh monscript.tesh | cat”)

La solution est d’utiliser “fflush(stdout)” après le printf pour forcer l’envoi des caractères vers la sortie.

1.23 2017-12-11 Résultats des tests blancs

Les résultats des tests blancs sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-11/VOTREPROJET.html.

Prochains tests aux alentours du 19/12/2017 (peut-être le 18/12 au soir).

1.24 2017-12-16 Résultats des tests blancs

J’ai fait tourner une série de tests blancs supplémentaires (qui ne remplacent donc pas ceux prévus le 19/12).

Les résultats sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-16/VOTREPROJET.html.

Quelques tests supplémentaires ont été ajoutés.

J’en profite pour signaler que je serai en déplacement du 19/12 soir au 21/12 soir, et donc très peu disponible pour répondre à vos questions (et en particulier, à celles qui n’incluent pas les informations demandées dans l’entrée du 2017-10-26).

Pensez à vérifier que vous avez bien complété le fichier AUTHORS, et n’oubliez pas de committer votre rapport.

1.25 2017-12-16 Notation du projet

Comptez-vous rajouter des tests d’ici au rendu ?

Je n’ai pas de tests “en réserve”, et les tests actuels couvrent a priori plutôt bien le sujet. Il est possible que j’en rajoute pour mettre en évidence des différences entre deux projets. Mais de toute manière, il faut prendre les résultats comme une manière de vérifier que votre projet fonctionne, et éviter de trop programmer en fonction des tests.

Devons-nous passer tous les tests pour avoir une note finale correcte/bonne ? Si non, quel est l’ordre de grandeur des tests qu’on doit passer ?

Un projet qui passerait tous les tests répondrait de manière quasi-parfaite à ce qui est demandé, et devrait avoir une note proche de 20 (peut-être un peu moins, en fonction par exemple de la qualité de l’implémentation).

A la louche (et à titre complètement indicatif à ce stade), le barème pourrait ressembler à :

Ce qui amène à 12.5 points pour des fonctionnalités qui (à l’exception de prompt1/prompt2) ont été discutées en cours, en TD ou en TP. Bien sûr, il reste le parsing de la ligne de commande (mais aucun de ces tests n’a plus de deux commandes par ligne, donc même une implémentation basique du parsing de ligne de commande est suffisante).

1.26 2017-12-17 Erreur test no_fd_leak5

Il y a une erreur dans la sortie attendue pour le test no_fd_leak5: la ligne “3->pipe” est en trop. Il est donc possible que votre résultat pour ce test soit l’inverse de celui indiqué. Merci à Olivier Dautricourt de l’avoir signalé.

Par ailleurs, si vous ne comprenez pas ces tests, je vous conseille cette définition, l’exercice 3 du TD 2, ou cette page qui explique pourquoi ce type de bugs peut être dangereux.

1.27 2017-12-19 Résultats des tests blancs

Les résultats des tests blancs sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-19/VOTREPROJET.html.

Le “rendu” final sera fait vendredi à 16h. Vous n’avez aucune opération particulière à effectuer autre que de vous assurer que votre git est dans l’état souhaité.

1.28 2017-12-21 Résultats des tests blancs

J’ai relancé des tests blancs sur un sous-ensemble des tests. Il y a également trois nouveaux tests.

Les résultats sont disponibles sur https://members.loria.fr/lnussbaum/RS2017/2017-12-21/VOTREPROJET.html.

Le “rendu” final sera fait vendredi à 16h. Vous n’avez aucune opération particulière à effectuer autre que de vous assurer que votre git est dans l’état souhaité.

2 Supports

3 Bibliographie et autres pointeurs utiles

Si vous avez des suggestions pour compléter cette partie, elles sont les bienvenues; voir également les premiers slides du cours.

3.1 Autres cours disponibles sur Internet

3.2 Sites d'information

3.3 Sur le langage C

4 Archives

4.1 Projets

4.2 Sujets d'examens